CH6. 생성 디자인 패턴

6.3 팩터리 패턴 (1)

6.3.2 팩터리 메서드 패턴

• 코드 펼치기
• 단순 팩터리 패턴에서 if 분기를 제거한 것. 다형성을 활용한다.
• 새 Parser 가 추가되면 ClassFactory 인터페이스를 구현하는 Factory 클래스를 추가하면 된다.
  • 단순 팩터리 패턴보다 개방 폐쇄 원리에 더 가깝다 : 기존 코드를 수정(예: if-else 문 수정 등)하지 않고 새 클래스를 추가하기만 하면 되므로
• 단순 팩터리 패턴 vs 팩터리 메서드 패턴
  • 객체의 생성 논리가 단순한 경우(예: 꼴랑 return new MyClass(); 뿐이라면) 단순 팩터리 패턴 을 사용하자.
  • 객체 생성 논리가 복잡한 경우 팩터리 메서드 패턴 을 사용해 생성 작업을 여러 팩터리 클래스로 분할하자.

6.3.3 추상 팩터리 패턴

• 코드 펼치기
• 팩터리가 한 가지 유형의 class 객체만 만들수 있다면 팩터리 클래스의 수가 너무 많아질 수 있다.
• 예시와 같이 추상 팩터리 패턴을 사용하면 팩터리가 다양한 유형의 class 객체를 만들게 할 수 있다. 이를 통해 팩터리 클래스의 수를 효과적으로 줄일 수 있다.

6.3.4 팩터리 패턴의 적용 대상

• 객체 생성 과정이 복잡한 경우 팩터리 패턴을 사용하자.
  • 객체 생성 과정을 캡슐화하고 객체의 생성과 사용을 분리하여 코드의 복잡성을 줄일 수 있다.
  • 객체 생성 과정이 복잡한 경우
    • 객체 생성 코드에 if 분기가 있으며, 분기에 따라 다른 객체를 동적으로 생성하는 경우
    • 분기에 따라 다른 객체를 생성할 필요는 없으나, 단일 객체 자체의 생성 프로세스가 복잡한 경우
      • 다른 클래스의 객체와 합성 or 다양한 초기화 작업이 필요한 경우
• 정리 : 팩터리 패턴의 역할
  • 팩터리 패턴을 사용하여 생성 과정을 캡슐화할 수 있다.
    • 호출자는 생성 과정의 변경 사항을 알 필요가 없다.
    • 복잡한 생성 과정을 캡슐화하므로, 호출자는 객체 생성 방법을 알 필요가 없다.
  • 생성 과정을 팩터리 클래스로 추출한 후 재사용 할 수 있다.
  • 생성 과정과 사용 과정을 분리하여 복잡한 코드를 간결하게 바꿀 수 있다.

6.4 팩터리 패턴 (2)

<aside> 📚 팩터리 패턴은 의존성 주입 컨테이너에서 널리 사용된다. 의존성 주입 컨테이너의 구현 원리를 분석해보자.

</aside>

6.4.1 DI 컨테이너와 팩터리 패턴의 차이