✔︎ factory method pattern
- 객체 생성 처리를 서브 클래스로 분리해 처리하도록 캡슐화하는 패턴
- 객체의 생성 코드를 별도의 클래스 또는 메서드로 분리하여 객체 생성 변화에 대비할 수 있다.
- 특정 기능의 구현은 개별 클래스를 통해 제공되는 것이 바람직하다.
- 기능의 변경이나 상황에 따른 기능의 선택 → 객체를 생성하는 코드의 변경을 초래
- 상황에 따라 적절한 객체를 생성하는 코드는 중복될 수 있다.
- 객체 생성 방식의 변화는 해당되는 모든 코드 부분을 변경해야 하는 문제가 발생한다.
장점
- 객체 생성을 한 곳에 모아 놓음으로서 한 부분의 수정이 다른 부분에 영향을 미치지 않게 된다.(SRP 준수)
- 변경에 다른 부분에 영향을 주지 않아 확장에 용이하다.(OCP 준수)
단점
상속을 이용한 factory method pattern
- Product
- 팩토리 메서드로 생성될 객체의 공통 인터페이스
- ConcreteProduct
- Creator
- ConcreteCreator
- 팩토리 메서드를 구현하는 클래스로 ConcreteProduct 객체를 생성
예제 코드
factory method pattern 예제 코드
참고
✔︎ abstract factory method pattern
- 구체적인 클래스에 의존하지 않고 서로 연관되거나 의존적인 객체들의 조합을 만드는 인터페이스를 제공한다.
- 관련성 있는 여러 종류의 객체를 일관된 방식으로 생성하는 경우에 유용하다.
- AbstractFactory
실제 팩토리 클래스의 공통 인터페이스
- ConcreteFactory
- 구체적인 팩토리 크래스로 AbstractFactory 클래스의 추상 메서드를 오버라이딩함으로서 구체적인 제품을 생성한다
- 싱글톤 패턴 적용을 하면 좋다
- AbstractProduct
제품의 공통 인터페이스
- ConcreteProduct
구체적인 팩토리 클래스에서 생성되는 구체적인 제품
예제 코드
abtract factory method pattern 예제 코드
참고
✔︎ factory method pattern VS abstract factory method pattern
factory method pattern
- 하나의 메서드가 여러 종류의 객체를 생성한다
- ex) DoorFactory의 createDoor() → ADoor or BDoor or CDoor
abstract method pattern
- Factory object 별 한 종류의 객체를 생성한다
- 제품군 형성시 유용
- ex) AFacotry의 createDoor() → ADoor
참고
SOLID 관점의 factory method pattern, abstract factory method pattern
- DIP 준수하는 설계로 구상 클래스에 대한 의존성 낮춘다.