Egoist

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 등 다양한 드라이버 지원).
• 게임 개발에서 월드 생성 시스템.

Factory Method 패턴은 생성 패턴의 한 종류로, 객체 생성에 대한 책임을 서브클래스로 위임하여, 객체 생성 방식을 캡슐화하고 클라이언트가 객체 생성 방식에 독립적으로 동작하도록 합니다. 객체 생성이 필요한 경우 이 패턴을 사용하여 클라이언트 코드의 유연성과 확장성을 높일 수 있습니다. 다음은 C++를 기준으로 Factory Method 패턴의 구조와 코드 예제를 포함하여 자세히 설명합니다.

Factory Method 패턴의 구조

1. Product (제품 인터페이스): 생성될 객체들이 구현해야 할 인터페이스 또는 추상 클래스입니다.
2. ConcreteProduct (구체적 제품): Product 인터페이스를 구현하는 실제 클래스들로, 다양한 형태의 Product 객체가 됩니다.
3. Creator (생성자 인터페이스): 팩토리 메서드 (FactoryMethod())를 정의하는 인터페이스로, 객체 생성 로직을 서브클래스에서 구현하도록 위임합니다.
4. ConcreteCreator (구체적 생성자): Creator 클래스를 상속하여, 특정 구체적 제품 객체를 생성하는 팩토리 메서드를 구현한 클래스입니다.

동작 과정

1. 클라이언트 코드는 Creator의 인스턴스에게 FactoryMethod를 호출하여 Product 타입의 객체 생성을 요청합니다.
2. ConcreteCreator는 FactoryMethod를 통해 ConcreteProduct의 객체를 생성하고, 이를 Product 타입으로 반환합니다.
3. 클라이언트는 Product 인터페이스만을 사용하여 객체와 상호작용합니다. 구체적으로 어떤 객체가 생성되었는지 알 필요가 없습니다.

C++ 코드 예제

1. Product 인터페이스와 구체적인 제품 클래스들

• Product는 객체 생성 결과로 얻을 수 있는 공통 인터페이스입니다. 각 제품 클래스는 Operation이라는 순수 가상 함수를 구현해야 합니다.
• ConcreteProductA와 ConcreteProductB는 Product를 상속받아 구체적인 제품 기능을 제공합니다

2. Creator 클래스와 구체적인 생성자 클래스들

• Creator는 FactoryMethod()라는 순수 가상 함수를 통해 제품 객체를 생성하는 인터페이스입니다. SomeOperation()이라는 함수는 FactoryMethod()를 호출하여 생성된 제품 객체와 작업을 수행합니다.
• ConcreteCreatorA와 ConcreteCreatorB는 Creator를 상속하며, 각기 다른 ConcreteProduct 객체를 생성하여 반환하는 팩토리 메서드를 구현합니다.

3. 클라이언트 코드

클라이언트는 Creator 인터페이스를 통해 제품을 생성하므로, 실제로 어떤 ConcreteProduct가 반환되는지 알 필요가 없습니다.

이 예제에서는 ClientCode 함수가 Creator 객체를 통해 작업을 수행합니다. SomeOperation() 메서드가 제품 생성 과정을 감추므로, 클라이언트는 구체적인 생성자 클래스가 어떤 제품을 생성하는지 알 필요가 없습니다.

출력 결과

이 코드를 실행하면 다음과 같은 출력이 나옵니다:

패턴의 장점과 단점

장점

1. 유연성: 클라이언트가 객체 생성에 구체적으로 관여하지 않아, 새로운 제품을 추가할 때 기존 클라이언트 코드를 수정할 필요가 없습니다.
2. 객체 생성 캡슐화: 객체 생성 로직이 숨겨져 있어 코드가 더 간결하고 유지보수하기 쉽습니다.
3. 확장성: 새로운 제품을 추가할 때 ConcreteCreator와 ConcreteProduct만 추가하면 되므로 코드의 확장성이 높습니다.

단점

1. 클래스 수 증가: 새로운 ConcreteProduct와 이를 생성하는 ConcreteCreator가 필요하기 때문에 클래스 수가 늘어나 복잡도가 높아질 수 있습니다.
2. 설계가 복잡해질 가능성: 팩토리 메서드 패턴을 사용하지 않아도 충분한 경우에도 과도하게 적용하면 코드가 불필요하게 복잡해질 수 있습니다.

활용 사례

• 다양한 객체 생성이 필요한 상황: 예를 들어, 그래픽 프로그램에서 다양한 도형(원, 사각형, 삼각형 등)을 생성해야 하는 경우 각 도형별로 ConcreteProduct와 ConcreteCreator를 두면 코드 확장성이 높아집니다.
• 객체 생성 로직이 복잡하거나 특정 조건에 따라 다른 객체를 생성해야 하는 경우: 다양한 요구 사항에 따라 객체 생성 방식이 달라질 때 유용합니다.

이로써 Factory Method 패턴을 C++로 구현하여 클라이언트와 객체 생성 로직을 분리하는 방법을 이해할 수 있습니다.