[Design Pattern] 추상 팩토리 패턴 (Abstract Factory)

Abstract Factory Pattern

추상 팩토리 패턴은 서로 관련 있는 객체들의 구상 클래스들을 일일이 지정하지 않고 인터페이스를 통해 일관성 있게 생성할 수 있는 생성 디자인 패턴입니다.

현실과 거리가 멀지만 한 가지 예시를 들어보겠습니다.
삼성과 애플의 노트북 생산 공장에서 각 사에서 자사 또는 LG의 디스플레이(Display)와 본체(Body)를 조립한다고 가정해보겠습니다.
팩토리 메서드 패턴만 적용한 상태에서 다음과 같은 다이어그램을 그릴 수 있습니다.

이 경우에는 LaptopFactory에서 클라이언트에서 전달받은 Samsung 또는 Apple 키워드를 DisplayFactory와 BodyFactory에 각 부품 생산을 위임하고 실제 DisplayFactory와 BodyFactory의 generate 메소드에서 다음과 조건 비교를 통해서 부품을 생성하게 됩니다.

• (가정) 삼성 노트북 : 삼성 디스플레이 + 삼성 본체
• (가정) 애플 노트북 : 애플 디스플레이 + 애플 본체

2가지 객체를 조합하는 경우는 크게 문제있어 보이지 않지만 마우스, 충전기 등 계속 조립할 부품의 Factory가 증가한다면?
일관성을 유지하기 어렵고 각 부품의 Factory에서 조건 비교해야 할 코드가 늘어날 것입니다.

추상 팩토리 패턴을 적용하면 어떻게 구조가 변경될까요?

먼저, 일관성을 유지하도록 부품 Factory를 없앤 뒤 각 사 마다 LaptopFactory를 두도록 인터페이스를 정의합니다.
그다음 LaptopFactory에 노트북 생산 오더를 내릴 Orderer를 정의합니다. 그렇게 되면 클라이언트는 Orderer를 통해서 노트북 생산을 요청을 할 수 있게 됩니다.

구조가 복잡하게 보이지만 일관성이 높아진 것을 확인할 수 있습니다. 추상 팩토리 패턴을 적용하여 얻는 장단점은 아래와 같습니다.

장점

• Factory에서 생성되는 객체들의 상호 호환을 보장할 수 있게 됩니다.
• 구상 객체들과 클라이언트 코드 사이의 결합도를 낮출 수 있습니다.
• 단일 책임 원칙(SRP)을 준수합니다.
  구상 객체 생성 코드를 한 곳으로 추출하여 유지보수성을 높여줍니다.
• 개방 폐쇄 원칙(OCP)를 준수합니다.
  기존 클라이언트 코드를 훼손하지 않고 새로운 조합의 팩토리로 확장 가능합니다.

단점

• 새로운 인터페이스와 클래스가 다수 생성되기 때문에 필요 이상으로 구조와 코드가 복잡해질 수 있습니다.

참조

refactoring.guru
Example 참조