로버트 마틴이 말하는 Factory Pattern 이란 무엇인가?

Photo by Joshua Sortino on Unsplash

반 버논의 도메인 주도 설계에서 팩토리 패턴에 대한 설명이 나옵니다.

 반버논이 말하는 팩토리 패턴이란? 

이 때와 반버논 책과 중복된 내용도 있지만, 평소 팩토리패턴에 대해서 생각하던 부분과 마침 책에서 다시와서 읽으면서 느낀바를 다시금 정리하고자 관련 내용을 적습니다.

배경

클린 소프트웨어 라는 책은, 객체지향프로그래밍 원칙인 SOLID에 입각한 샘플 프로젝트 코드와, 물론 SOLID도 설명하구요. 마찬가지로 SOLID 원칙 중, 의존 관계 역전 법칙(DIP)에 해당하는 부분을 설명하기 위해 팩토리 패턴을 언급합니다. 

 개인적으로, DIP를 위해서 다양한 방법이 존재하는데, 템플릿 메소드 패턴- 전략패턴등 여러 방법이 있다고 생각합니다. 팩토리 패턴도 다양한 방법 중 하나인데, DIP을 정말 잘 활용하기 위해서는 팩토리 패턴뿐만 아니라, 여러 패턴들을 융합해서 사용해야 된다고 개인적으로 생각합니다. 

로버트 마틴이 말하는 Factory Pattern은?

 

1. 의존성 역전

 책에서는 시작부터 DIP에 대한 언급을 시작하면서 팩토리 패턴을 설명합니다. 의존 관계 역전 법칙은 구체 클래스에 의존하는 것은 피하고 추상 클래스에 의존하는 것을 선호하는 것을 말합니다. 이런 경우는 대부분 구체 클래스가 쉽게 변경되는 종류일 경우 더욱 해당되는 이야기입니다.

 바로 다이어그램을 하나 살펴보겠습니다.

 위 다이어그램은 DIP를 위배한다. DIP의 원칙은 구체 클래스에 의존하는 것은 피하고 추상 클래스에 의존하는 것을 선호하는 것이라고 말했습니다. 그러므로, 위 SomeApp은 Squre과 Circle 을 직접적으로 바라보는것이 아니고, 다시 말해, Squre, Circle 은 Some App을 직접적으로 접근해서는 안됩니다. 

여기서 Factory와 같은 중간 매체가 필요하게 됩니다. 아마도 아래와 같은 다이어그램일 듯합니다.

Some App 도 Factory을 바라보고, Factory 구현체도 Factory 인터페이스를 바라보는 방향으로 구현하게 되면, 의존성이 중간에 Factory에 의존하게 되면서 의존성 역전이 일어납니다.

2. 대체할 수 있는 팩토리

위 그림에서도 보여지는 것과 같이 Factory의 구현은 다른 구현으로 대체할 수 있다는 점. 그렇게 함으로써- 어플리케이션 안에 있는 객체들의 집합 하나를 다른 집합으로 통채로 대체할 수 있습니다.

책에서의 예시와는 다르게, 스프링 프레임워크의 JPA를 예시로 들을 수 있을 것 같습니다. JPA를 잘 활용한다면, 언제든 MySQL, Oracle 기타 등등의 DB를 사용할 수 있을 것입니다. 물론 이상적인 이야기이지만, 이론적으로 각각에 맞는 JPA에서 각 DB에 맞는 다이렉트를 만들어 사용할 수 있을 것입니다.

3. 팩토리 사용이 얼마나 중요한가?

 만약, DIP을 엄격하게 적용한다면, 시스템에 들어 있는 쉽게 변경되는 종류의 모든 클래스마다 팩토리를 사용해야 한다고 말합니다. 그러나,  로버트마틴은 극단적으로 DIP를 사용하는 것을 권장하지 않는다고 합니다.

 처음에는 팩토리를 사용하지 않고 시작하고, 팩토리의 필요성이 충분히 커지면 그제야 시스템에 팩토리를 도입한다.
예를 들면, 프록시 패턴을 사용해야만 하게 된다면, 영속적인 객체들을 생성하기 위해 팩토리도 사용해야만 할 것이다. 또 다른 예로- 다른 객체를 생성하는 어땐 객체가 있다고 할 때, 단위 테스트를 하는 동안 이 객체를 스푸핑해야만 하는 상황도 종종 만나게 될 것이다. 그러면 아마도 그때, 팩토리 패턴을 사용할 것 같다.

로버트 마틴의 내린 팩토리패턴에 대한 생각이다.

---

마무리&내 생각

 객체지향프로그래밍에서는 각 객체가 지니고 있는 역할, 책임, 협력 관점에서 중요한 의미를 가지고 있다고 생각합니다. 그렇기 때문에, 제가 속해있고 일하는 도메인 분야에 대한 지식 학습은 무조건으로 중요하다고 생각합니다.

 다시 본론으로 들어가서, 팩토리 패턴은 각 객체가 역할과 책임 그리고 협력을 하는 관점에서 적절하게 분배시켜줄 수 있는 역할을 하는 좋은 도구라고 생각합니다. 그 이유로 위에서 언급한 DIP도 하나의 이유가 되고, DDD에서 말하는 팩토리패턴에 따르면, 아키텍쳐의 확장성을 도와줄 수 있습니다.

 디자인 패턴을 학습하고 이해하면서 점차 커지는 공감은, 디자인 패턴은 설계의 확장성을 위해서 태어났다 라는 말에 대해서 점점더 공감되게 됩니다.
 디자인 패턴을 자세히 뜯어보면, 정말 아주 찰나의 차이가 서로 다른 이름으로 불리게 되며- 이를 하나의 패턴으로 정의합니다. 실제 실무에서 사용되는 방식은 단 한개의 패턴이 아닌- 다양한 패턴이 나도 모르게 합쳐져 사용됩니다.