[Spring Framework] 부품화의 문제

웹 애플리케이션을 구축하는 오브젝트 사이의 의존 관계는 인터페이스를 매개로 해서 구현에 의존하지 않음으로써 오브젝트 사이를 약한 결합으로 유지할 수 있다. 또한, 그렇게 함으로써 오브젝트를 쉽게 확장-변경하고, 개발 효율을 올리며, 시스템을 고품질로 유지할 수 있음은 앞에서 설명했다. 

예를 들어 오브젝트가 인터페이스에만 의존하면 인터페이스가 확장/변경되더라도 이용하는 오브젝트에는 아무 영향도 주지 않는다. 

 

 

또한, 인터페이스의 배후에 있는 오브젝트가 미완성일 때에도 mock 오브젝트로 치환해 개발을 중단하지 않고 진행할 수 있으며, 테스트용 클래스로 치환해 손쉽게 테스트를 시행할 수 있다. 

 

이러한 사고방식을 적극적으로 밀고 나가면 전자 제품처럼 부품별로 개발 거점을 나누어 작성할 수 있다.

 

※ 물론 Mockito(의존하는 클래스를 mock으로 치환해줌, http://mockito.org/)를 사용하면 인터페이스가 없더라도 개발할 수 있다. 단, 어느 정도 큰 규모에서 개발할 경우에는, 팀 간의 경계선에 인터페이스가 필요할 것이고, 부품화에 따라서 명확하게 하기 위해서도 필요하다. 가능하면 UML(실제 관계와 사용 의존) 같이, 실현되는 인터페이스와 실현되지 않는 인터페이스를 명확하게 구분할 수있게 두 종류의 인터페이스가 필요할 것이다.

 

 

하지만 스프링와 같은 프레임워크를 이용하지 않고 이러한 인터페이스 의존/구현 비의존을 실현하려면 고도의 기술이 필요하다. 예를 들어, 단순히 인터페이스를 이용하는 것만으로는 구현 비의존을 실현할 수 없다.

 

 

그래서 보통은 팩토리 메서드(Factory Method) 등을 도입해서 구현 비의존을 실현한다.

 

 

※ 팩토리 메서드는 디자인 패턴 중 하나이다. 여기서 자바의 리플렉션 기능을 이용해 new 연산자를 사용하지 않고 인스턴스화하는 것을 가리키고 있다. 팩토리 메서드에 관한 자세한 내용은 디자인 패턴 관련 서적 등을 참고하고, 자바의 리플렉션 기능에 관해서는 자바 관련 서적 등을 참고하자.

 

하지만, 현실에서는 의존과 비의존을 만들어가는 것 자체를 모르거나 혹은 비용이 많이 발생한다고 여기는 경우가 많다. 그러면 결국 인터페이스에 의존하고 구현에 의존하지 않는 설계/구현이 이루어지지않고, 개발 효율과 변경/확장의 용이성, 테스트에 의한 품질 유지를 달성할 수 없다.