Egoist

C++에서 **빌더 패턴(Builder Pattern)**은 생성 패턴(Creational Pattern)의 한 유형으로, 복잡한 객체를 단계적으로 생성하는 데 사용됩니다. 빌더 패턴은 특히 생성 과정에서 객체를 구성하는 세부 사항이 많거나, 동일한 생성 절차로 다양한 표현을 생성해야 할 때 유용합니다. 이 패턴은 객체의 생성과 표현을 분리하여, 동일한 생성 코드에서 다양한 객체를 만들 수 있도록 설계되었습니다.

빌더 패턴의 주요 구성 요소

1. Builder 인터페이스
   • 객체 생성의 단계를 정의하는 추상 인터페이스입니다.
   • 제품(Product)을 구성하는 여러 부분을 설정하는 메서드를 포함합니다.
2. ConcreteBuilder(구체적 빌더)
   • Builder 인터페이스를 구현하여 객체를 단계적으로 생성합니다.
   • 완성된 제품(Product)을 반환하는 메서드도 포함합니다.
3. Director(감독자)
   • Builder 객체를 사용하여 객체를 생성하는 데 필요한 단계를 정의하고 실행하는 역할을 합니다.
   • 객체 생성 순서를 제어하며, 빌더의 메서드를 호출하여 객체를 완성합니다.
4. Product(제품)
   • 생성되는 최종 객체입니다.
   • 복잡한 구조를 가지며, 빌더에 의해 단계적으로 생성됩니다.

C++ 구현 예제

다음은 간단한 예제로, 빌더 패턴을 사용하여 복잡한 Car 객체를 생성하는 경우를 보여줍니다.

1. Product 클래스

• 역할
  Car는 최종적으로 생성되는 객체입니다.
  여기에는 자동차의 엔진, 바퀴, 색상 등 여러 속성이 정의되어 있습니다.
• 특징
  ShowSpecifications() 메서드를 통해 생성된 객체의 속성을 확인할 수 있습니다.

2. Builder 인터페이스

• 역할
  Builder 인터페이스는 Car 객체를 구성하기 위한 구성 단계를 정의합니다.
• 주요 메서드
  • BuildEngine(): 엔진 설정.
  • BuildWheels(): 바퀴 설정.
  • Paint(): 자동차 색상 설정.
  • GetCar(): 최종적으로 완성된 Car 객체를 반환.
• 특징
  이 인터페이스를 구현하는 구체적 빌더는 Car의 속성을 단계별로 설정합니다.

3. ConcreteBuilder

• 역할
  SportsCarBuilder는 CarBuilder를 구현하여 스포츠카를 단계적으로 생성합니다.
• 구성 단계
  • BuildEngine(): Car의 engine 속성을 "V8 Engine"으로 설정.
  • BuildWheels(): wheels 속성을 "18 inch Alloy Wheels"로 설정.
  • Paint(): color 속성을 "Red"로 설정.
• 특징
  • Car* car: 생성 중인 Car 객체를 저장.
  • 객체 생성이 끝나면 GetCar() 메서드를 통해 완성된 객체를 반환합니다.

4. Director 클래스

• 역할
  Director는 빌더를 사용하여 Car를 생성하는 순서를 정의합니다.
• 특징
  • CarBuilder* builder: 사용할 빌더 객체를 보관.
  • Construct(): 빌더의 메서드를 호출하여 객체 생성 과정을 실행.
• 장점
  • 빌더가 Director와 협력하므로, 객체 생성의 순서와 논리를 분리할 수 있습니다.
  • 동일한 Director를 사용하더라도 다른 ConcreteBuilder를 전달하면 다양한 객체를 생성할 수 있습니다.

5. 클라이언트 코드

• 1단계: 빌더 생성  
  • SportsCarBuilder는 스포츠카를 생성하기 위한 빌더입니다.
     
• 2단계: Director 생성 및 빌더 전달
  • Director는 빌더를 받아서 객체 생성의 절차를 정의합니다.
• 3단계: 객체 생성
  • Director가 빌더의 BuildEngine(), BuildWheels(), Paint() 메서드를 호출하여 객체를 단계적으로 구성합니다.
• 4단계: 완성된 객체 확인
  • 완성된 Car 객체를 반환받고, 속성을 출력합니다.
• 마지막 단계: 메모리 정리
  • 동적으로 생성된 객체를 명시적으로 삭제하여 메모리 누수를 방지합니다

확장 가능성

• SportsCarBuilder 외에 다른 빌더(SUVBuilder, TruckBuilder 등)를 추가하면 다양한 유형의 자동차를 생성할 수 있습니다.
• Director는 동일한 로직으로 다른 빌더를 사용할 수 있으므로, 객체 생성의 유연성이 증가합니다.

빌더 패턴의 장점

1. 복잡한 객체 생성 단순화
   • 객체 생성의 세부 사항을 캡슐화하여 복잡성을 줄일 수 있습니다.
2. 객체 생성의 유연성 증가
   • 동일한 생성 과정을 사용하여 다양한 유형의 객체를 생성할 수 있습니다.
3. 객체의 생성 코드와 표현 분리
   • 객체 생성에 필요한 세부 정보를 클라이언트 코드에서 분리합니다.

빌더 패턴의 단점

1. 구현 복잡성 증가
   • 객체를 구성하는 단계와 인터페이스를 정의해야 하므로 코드가 다소 복잡해질 수 있습니다.
2. 단일 제품군에만 적합
   • 동일한 생성 단계를 공유하는 제품군에는 적합하지만, 생성 방식이 크게 다른 경우에는 불편할 수 있습니다.

빌더 패턴은 주로 객체 생성이 복잡하거나 다양한 조합으로 객체를 생성해야 할 때 사용됩니다. 잘 설계된 빌더 패턴은 코드의 가독성과 재사용성을 높이는 데 매우 효과적입니다.

Abstract Factory는 객체 생성의 추상화를 통해 서로 관련 있거나 독립적인 객체 그룹을 생성할 수 있도록 설계된 생성 패턴입니다. 이 패턴은 구체적인 클래스의 인스턴스를 직접 지정하지 않고, 객체 생성 인터페이스를 제공하여 구현 간의 결합도를 줄이는 데 중점을 둡니다.

C++에서 이 패턴은 다양한 객체 생성 작업을 캡슐화하고 서로 관련된 객체들이 일관되게 생성되도록 보장합니다. 이 과정에서 객체 생성의 구체적인 세부사항을 클라이언트 코드로부터 숨기며, 클라이언트는 단순히 팩토리를 호출하기만 하면 됩니다.

Abstract Factory 패턴의 핵심 원리

1. 객체 생성의 추상화

클라이언트 코드에서 제품 객체를 직접 생성하지 않고, 팩토리를 통해 생성합니다.
즉, 구체적인 제품 클래스는 클라이언트 코드에서 노출되지 않습니다.

구성 요소

1. Abstract Factory (추상 팩토리)
   • 객체를 생성하기 위한 인터페이스(순수 가상 클래스)를 정의합니다.
   • 제품군(Product Family)에 속하는 객체들을 생성하는 역할을 담당합니다.

   

2. Concrete Factory (구체 팩토리)
   • Abstract Factory를 구현하여 구체적인 객체 생성 논리를 제공합니다.
   • 각 팩토리는 특정 플랫폼이나 요구사항에 맞는 제품군 객체를 생성합니다.

   

    
3. Abstract Product (추상 제품)
   • 팩토리가 생성할 객체들의 공통 인터페이스를 정의합니다.
   • 이를 통해 제품군 내 객체들 간의 일관성을 유지할 수 있습니다.

   

4. Concrete Product (구체 제품)
   • Abstract Product를 실제로 구현한 클래스입니다.
   • 예를 들어, Windows와 Mac 환경에 각각 적합한 Button과 Checkbox를 정의합니다.

   

5. Client (클라이언트)
   • Abstract Factory와 Abstract Product에 의존합니다.
   • 구체적인 제품 클래스나 팩토리를 알 필요가 없습니다.

     

Abstract Factory 작동 흐름

1. 팩토리 생성
   클라이언트는 특정 환경에 맞는 팩토리 객체를 생성합니다.
   예: WindowsWidgetFactory, MacWidgetFactory.
2. 객체 생성 요청
   클라이언트는 팩토리 객체를 통해 필요한 제품군의 객체를 생성합니다.
   제품군 내의 객체들(Button, Checkbox 등)은 서로 독립적으로 생성되지만, 같은 컨텍스트(Windows, Mac 등)에 속합니다.
3. 제품 사용
   생성된 객체는 인터페이스(추상 클래스)를 통해 사용되며, 클라이언트는 구체적인 구현을 알 필요가 없습니다.

실제 예제: 운영 체제 기반 UI

운영 체제에 따라 다른 UI 위젯을 제공하는 예를 들어보겠습니다.

출력 결과

Abstract Factory의 장점

1. 일관성 유지:
   제품군 내 객체들은 항상 같은 컨텍스트에 속하므로, 일관성이 유지됩니다.
   • 예: Windows 팩토리는 Windows 스타일의 버튼과 체크박스만 생성.
2. 유연성 증가:
   클라이언트는 제품의 구체적인 구현에 의존하지 않습니다. 따라서 쉽게 교체하거나 확장할 수 있습니다.
3. 의존성 역전 원칙(DIP) 준수:
   클라이언트는 구체적인 클래스가 아니라 추상화된 인터페이스에 의존합니다.

Abstract Factory의 단점

1. 복잡성 증가:
   많은 인터페이스와 클래스가 추가되므로 코드가 복잡해질 수 있습니다.
2. 확장 시 추가 작업:
   새로운 제품군을 추가하려면 관련된 팩토리와 제품 클래스를 모두 정의해야 합니다.

활용 사례

• 크로스 플랫폼 UI 라이브러리 (Qt, GTK 등).
• 데이터베이스 연동 라이브러리 (Oracle, MySQL 등 다양한 드라이버 지원).
• 게임 개발에서 월드 생성 시스템.