첫소감
- FactoryMethod 패턴은 들어봤어도 Abstract Factory Pattern은 솔직히 처음 접해봤다.
의도
상세화된 서브 클래스를 정의하지 않고도 서로 관련성이 있거나 독릭적인 여러 객체의 군을 생성하기 위한 인터페이스 제공
다른이름
동기
아래 구조를 보면서 비교
- 다른 이름인 키트에 주목해야한다.
- 키트란? 하나의 묶음 그 전부를 의미한다. SDK의 K가 Kit에 해당한다.
- 책에서 제시하는 모티프나 프레젠테이션 매니저가 뭔지 모르겠어서 직관적인 다른예시를 찾아보았다.
- 스마트폰 공장 예시
- 스마트폰이 있고, 스마트폰은 AP와 배터리를 구성품으로 가진다.
- 스마트폰을 생성해주는 공장이 존재함 (AbstractFactory)
- 스마트폰을 생산하는 공장으로 애플과 삼성이 있다. (ConcreteFactor1, ConcreteFactor2)
- 애플 또는 삼성 공장에서는 AP와 배터리를
- Client는 Abstract 스마트폰 공장에 생성을 요청하면, 애플 또는 삼성 스마트폰 Instance를 생성해 준다.
- Client는 어떤걸 ConcreteFactory를 몰라도 된다.
- 대신 애플,삼성 공장은 AP나 Battery를 항상 생성해줘야하는 제약이 생김
활용성
- 추상팩토리를 사용하는 경우
- 객체가 생성되거나 구성-표현되는 방식과 무관하게 시스템을 독립적으로 만들고자 할 때.
- 여러 제품군 중 하나를 선택해서 시스템을 설정해야하고 한번 구성한 제품을 다른 것으로 대체할 수 있을 때
- 관련된 제품 객체들이 함께 사용되도록 설계되었고, 제약이 있을 때
- 제품에 대한 클래스 라이브러리를 제공하고, 구현이 아닌 인터페이스를 노출 시키고 싶을 때
2,3번이 핵심인듯. Kit라는 별칭에 주목하자.
구조

참여자
- AbstractFactory(SmartPhoneFacotry)
- 개념적 제품에 대한 객체를 생성하는 method로 인터페이스 정의
- ConcreteFactory(ApplePhoneFacotry, SamsungPhoneFactory)
- AbstractProduct
- ConcreteProduct(AppleAp, AppleBattery)
- Client
- AbstractFactory나 AbstractProduct 클래스에 선언된 인터페이스를 사용할 주체
협력 방법
- ConcreteFactory 클래스의 인스턴스 한개가 런타임에 생성됨
- AbstractFactory는 생성의 역할을 ConcreteFactory에 위임함
결과
- 구체적인 생성 클래스 분리
- 사용자는 구체적인 생성 방법에 대해서 몰라도 된다.
- 제품군을 쉽게 대체할 수 있음
- 이건 뭐 당연한듯 (Samsung -> Apple)
- 제품 사이의 일관성 증진
- AbstractFactory이라는 제약을 둠으로써 제품군(SmartPhone)에 제약을 둘 수 있음
- 제품 자체의 확장에 취약
- 제품군 자체(SmartPhone에 카메라 기능이 추가되면?) 가 되면 모든 구체 클래스를 바꿔야함
구현
- 이건 나중에..
- 참여자에 있는 애들을 다 구현해보면 된다. Client는 Abstract Factory, Product만 알면 끝. (보통은 한개의 Concrete만 생성된다는 것을 기억하라., 물론 2개이상 쓰고 싶다면 쓰면 됨 )
소감
- Kit를 기억하자. 관행적으로 Concrete에 Kit를 붙인다고 한다.
- 업무중에 적용할 수 있었을 법한 일들이 생각이 난다. 회사가서 리펙토링 해야할 거리가 또 생긴듯
- 팩토리 메소드 패턴과 다른점은, 팩토리 메소드는 한 팩토리가 여러개의 Product를 생성할 수 있지만, Abstract Factory Pattern은 한 팩토리가 하나의 제품군 을 생성한다는 점에서 차이가 있음
참고자료 https://ko.wikipedia.org/wiki/%EC%B6%94%EC%83%81_%ED%8C%A9%ED%86%A0%EB%A6%AC_%ED%8C%A8%ED%84%B4