FACTORY 패턴이 필요한 이유
우리는 11장에서 DIP에 대해 배우면서, 구체적인 클래스에 의존하지 않고 사이에 인터페이스를 하나 두어서 추상화에 의존하도록 하는 방법을 배웠다. 하지만 어떤 클래스 내에서 다른 클래스를 새로 생성해야 할 때는 인터페이스가 존재하더라도 무조건 구체적인 클래스에 의존성을 가질 수 밖에 없다. Dependency Injection으로 외부에서 의존성을 주입해준다고 해도, 상위의 어떤 곳에서는 어쨌든 이 구체적인 클래스를 생성해야만 한다.
이러한 상황에서 적용할 수 있는 것이 바로 FACTORY 패턴이다. FACTORY 패턴을 활용하면 추상 인터페이스에만 의존하면서도 구체적인 클래스를 생성할 수 있다.
한 가지 의문은 팩토리 클래스를 사용한다고 해도 어쨌든 팩토리 클래스의 인스턴스를 어디선가 생성해야 하고, 그럼 구체적인 클래스에 의존하게 되어 DIP를 위반하게 되는 것은 아닐까?
이에 대해 내가 생각한 답은 팩토리 클래스는 아마도 싱글톤 패턴으로 인스턴스가 생성될 것이고, 그것이 생성되는 장소는 보통 어플리케이션의 가장 윗부분일 것이므로 DIP를 위반하더라도 크게 문제가 되지 않는다는 것이다.
어플리케이션의 모든 부분에서 DIP를 지킨다는 것은 사실 불가능하기 때문에, DIP 위반의 부작용이 가장 적은 방법을 택한 것이라고 볼 수 있을 것 같다.
대체 가능성
FACTORY 패턴의 장점 중 하나는 어떤 팩토리의 구현을 다른 구현으로 대체할 수 있다는 점이다. 따라서 어플리케이션 안에 있는 객체들의 집합 하나를 다른 집합으로 통째로 대체할 수 있다.
예를 들어, DB 연결에 대한 PROXY 객체가 있고, 이 객체들을 생성하는 팩토리 클래스가 있다고 해보자. DB 연결에 대한 방식은 일반 파일을 통해 이루어질 수도 있고, Oracle 어댑터를 이용해서 이루어질 수도 있다. 이런 상황에서 우리는 Factory 클래스의 두 가지 구현을 두어 하나의 객체 그룹이 다른 객체 그룹을 완벽히 대체하도록 할 수 있다.
팩토리 사용이 얼마나 중요한가?
DIP를 엄격하게 적용하기 위해서는 시스템 내에서 쉽게 변경되는 모든 클래스에 대해 팩토리 클래스를 만들어야 한다. 하지만 이는 오히려 소프트웨어로 하여금 불필요한 복잡성의 악취를 풍기게 할 수 있다.
보통 팩토리 클래스가 필요한 경우는 한정적이다. PROXY 패턴을 사용하기 위해 영속적인 PROXY 객체를 만들어야 하는 경우, 혹은 유닛 테스트에서 어떤 객체를 스푸핑해야 하는 경우 등에서는 팩토리의 사용이 적절할 수도 있다. 중요한 것은 우리는 팩토리의 사용을 염두에 두고 개발을 하지 않으며, 팩토리가 필요한 순간을 만나면 그 때 도입을 검토하면 된다는 것이다.
