추상 팩토리 패턴

추상 팩토리 패턴의 참여자는 크게 네 가지 주요 역할로 구성된다. 이들은 추상 팩토리, 구체 팩토리, 추상 제품, 구체 제품이다.

첫째, 추상 팩토리는 패턴의 핵심 인터페이스이다. 이 인터페이스는 서로 연관되거나 의존적인 제품 객체들의 집합을 생성하기 위한 연산들을 선언한다. 각 연산은 추상 제품 타입의 객체를 반환한다. 둘째, 구체 팩토리는 추상 팩토리 인터페이스를 구현한다. 이 클래스는 구체 제품 객체를 생성하는 연산을 실제로 구현하며, 특정 제품군에 속하는 객체들을 생성하는 책임을 진다. 예를 들어, 윈도우 팩토리는 윈도우 버튼과 윈도우 스크롤바를 생성한다.

셋째, 추상 제품은 생성될 제품 객체들의 공통 인터페이스를 정의한다. 예를 들어, 버튼이나 스크롤바와 같은 추상 타입이 이에 해당한다. 넷째, 구체 제품은 추상 제품 인터페이스를 구현하는 구체적인 클래스이다. 이들은 구체 팩토리에 의해 생성되며, 특정 구현을 제공한다. 윈도우 버튼과 맥 버튼은 모두 버튼이라는 추상 제품의 구체 제품이다.

이러한 참여자들은 클라이언트 코드가 구체 클래스에 직접 의존하지 않고도 연관된 객체들의 제품군을 생성할 수 있도록 협력한다. 클라이언트는 추상 팩토리와 추상 제품 인터페이스만을 통해 객체들과 상호작용한다.

추상 팩토리 패턴의 협력은 클라이언트, 추상 팩토리, 구체 팩토리, 추상 제품, 구체 제품이라는 다섯 가지 핵심 참여자 간의 명확한 흐름으로 이루어진다.

클라이언트는 추상 팩토리 인터페이스를 통해서만 제품 객체들을 생성한다. 클라이언트는 자신이 사용하는 팩토리가 어떤 구체 팩토리인지 알지 못하며, 생성되는 제품의 구체 클래스도 알지 못한다. 클라이언트는 추상 팩토리에 정의된 팩토리 메서드 패턴을 호출하여 추상 타입의 제품 객체를 얻는다. 예를 들어, createButton() 메서드를 호출하면 추상 버튼 객체가 반환되고, createCheckbox() 메서드를 호출하면 추상 체크박스 객체가 반환된다.

이 과정에서 구체 팩토리 객체는 런타임에 생성되어 클라이언트에 전달된다. 클라이언트는 이 구체 팩토리를 추상 팩토리 타입으로 참조한다. 구체 팩토리는 자신이 생성해야 하는 제품군을 결정하며, 각 팩토리 메서드를 구현하여 해당 제품군에 속하는 구체 제품 객체를 생성하고 반환한다. 예를 들어, Windows 팩토리는 createButton()에서 Windows 버튼 객체를, createCheckbox()에서 Windows 체크박스 객체를 반환한다. 이로 인해 클라이언트가 사용하는 모든 제품 객체는 동일한 테마나 제품군에 속하게 되어 일관성을 보장받는다.

결과적으로, 클라이언트는 특정 구현에 종속되지 않고 추상 인터페이스를 통해 제품 객체들을 조작할 수 있다. 새로운 제품군을 지원해야 할 때는 새로운 구체 팩토리 클래스를 구현하고, 런타임에 해당 팩토리 객체를 클라이언트에 설정하기만 하면 된다. 이는 클라이언트 코드의 변경 없이 제품군 전체를 교체할 수 있게 하는 핵심 협력 방식이다.

추상 팩토리 패턴의 UML 다이어그램은 패턴의 핵심 구성 요소와 그들 간의 관계를 시각적으로 표현한다. 이 다이어그램은 일반적으로 클래스 다이어그램으로 그려지며, 추상 팩토리, 구체적 팩토리, 추상 제품, 구체적 제품 클래스들 사이의 상속, 합성, 의존 관계를 명확히 보여준다.

다이어그램의 주요 구조는 다음과 같다. 하나의 추상 팩토리 인터페이스 또는 추상 클래스가 존재하며, 이는 여러 제품군을 생성하는 메서드(예: createProductA(), createProductB())를 선언한다. 이 추상 팩토리를 상속받아 구체적인 구현을 제공하는 여러 구체적 팩토리 클래스(예: ConcreteFactory1, ConcreteFactory2)가 있다. 각 구체적 팩토리는 특정 제품군에 속하는 모든 제품 객체들을 생성하는 책임을 진다. 제품 측면에서는 각 제품 유형(예: AbstractProductA, AbstractProductB)에 대한 추상 제품 인터페이스가 정의되고, 이를 구현하는 구체적 제품 클래스들(예: ProductA1/ProductA2, ProductB1/ProductB2)이 존재한다. 클라이언트는 추상 팩토리 타입을 통해 팩토리에 접근하며, 생성된 제품들도 각각의 추상 제품 타입으로 참조된다.

이 UML 다이어그램은 클라이언트 코드가 구체적인 클래스 이름을 직접 언급하지 않고도 관련 객체들의 군(family)을 생성할 수 있도록 하는 패턴의 본질, 즉 제품 생성의 책임을 팩토리로 캡슐화하고 제품군 전체를 교체 가능하게 만드는 구조를 한눈에 이해하는 데 도움을 준다.

추상 팩토리 패턴은 다음과 같은 상황에서 특히 유용하게 적용될 수 있다.

첫째, 시스템이 생성할 객체의 클래스를 명시하지 않고도, 서로 연관되거나 의존적인 객체들의 군을 생성해야 할 때이다. 예를 들어, 사용자 인터페이스(UI) 툴킷에서 윈도우, 버튼, 텍스트 상자 등이 일관된 스타일(예: Material Design, Flat Design)로 함께 생성되어야 하는 경우가 이에 해당한다. 패턴은 이러한 관련 객체 군을 생성하는 인터페이스를 제공하여, 구체적인 클래스를 코드에서 분리한다.

둘째, 여러 제품군 중 하나를 선택하여 시스템을 구성해야 하고, 구성된 제품군을 다른 것으로 대체할 수 있어야 할 때이다. 예를 들어, 애플리케이션이 운영 체제별(Windows, macOS, Linux)로 다른 네이티브 UI 컴포넌트를 사용해야 한다면, 각 OS에 대한 구체적인 팩토리를 구현하고 런타임에 적절한 팩토리를 선택하여 전체 UI 객체 군을 생성할 수 있다. 이는 시스템의 설정이나 환경에 따라 생성되는 객체 군을 유연하게 교체할 수 있게 만든다.

마지막으로, 제품 객체들이 함께 사용되도록 설계되었고, 이 상호 호환성을 보장해야 할 때 추상 팩토리 패턴이 적합하다. 패턴은 특정 구체 팩토리가 생성하는 모든 객체들이 서로 호환되도록 설계하는 것을 강제한다. 따라서 클라이언트는 서로 다른 팩토리에서 생성된 객체들을 혼합하여 사용하는 실수를 방지할 수 있다.

추상 팩토리 패턴은 생성할 객체의 군이 자주 변경되거나 확장될 때 유용합니다. 반대로, 생성할 객체의 종류가 고정되어 있고 변경될 가능성이 거의 없는 경우에는 이 패턴을 적용하는 것이 오히려 복잡성만 증가시킬 수 있습니다. 패턴을 도입하면 새로운 인터페이스와 클래스 계층이 생겨 코드베이스가 커지므로, 단순한 팩토리 메서드 패턴이나 직접적인 객체 생성으로 충분히 해결할 수 있는 문제에는 과도한 설계가 될 수 있습니다.

또한, 제품군을 구성하는 개별 제품들 사이에 실제로 연관성이나 일관성이 존재하지 않는 경우에도 추상 팩토리 패턴은 적합하지 않습니다. 이 패턴은 서로 다른 제품들이 함께 동작해야 하는 경우를 전제로 하기 때문입니다. 예를 들어, 서로 완전히 독립적인 GUI 버튼과 데이터베이스 연결 객체를 하나의 팩토리에서 생성해야 한다면, 이는 패턴의 본래 의도와 맞지 않습니다.

초기 개발 단계에서 요구사항이 명확하지 않거나 프로토타입을 빠르게 만들어야 할 때도 이 패턴의 도입을 지연하는 것이 좋습니다. 패턴의 구조를 설계하고 구현하는 데 드는 비용이 예상된 유연성의 이점보다 클 수 있기 때문입니다. 시스템이 매우 작거나 단순하여 제품군의 개념 자체가 필요하지 않은 경우에도 적용이 부적합합니다.

추상 팩토리 패턴의 주요 장점은 구체적인 클래스의 인스턴스화를 분리하여 시스템의 유연성과 일관성을 높이는 데 있다. 첫째, 제품군을 생성하는 인터페이스를 제공함으로써 클라이언트 코드가 구체적인 클래스에 의존하지 않게 한다. 클라이언트는 추상 제품 인터페이스를 통해 객체를 조작하므로, 실제로 생성되는 구체적인 제품군(예: Windows 위젯군 vs. macOS 위젯군)이 변경되어도 코드 수정 없이 교체할 수 있다. 이는 의존성 역전 원칙을 따르며, 시스템을 특정 구현으로부터 독립시킨다.

둘째, 제품군 내의 객체들이 함께 동작하도록 보장하여 일관성을 유지한다. 패턴은 상호 관련되거나 의존적인 객체들을 함께 생성하도록 설계되었기 때문에, 서로 호환되지 않는 제품(예: Windows 버튼과 macOS 스크롤바)이 조합되는 것을 방지한다. 이는 잘못된 객체 조합으로 인한 런타임 오류를 사전에 차단하는 효과가 있다.

또한, 새로운 종류의 제품군을 시스템에 추가하는 것이 비교적 용이하다. 새로운 구체 팩토리 클래스를 구현하고, 필요한 새로운 구체 제품 클래스들을 생성하기만 하면 된다. 기존의 클라이언트 코드는 변경할 필요가 없으며, 단지 새로운 팩토리 인스턴스를 생성자나 설정 메서드를 통해 주입받으면 된다. 이는 개방-폐쇄 원칙을 지원하는 형태이다.

마지막으로, 객체 생성 코드를 한 곳(팩토리 클래스들)에 집중시켜 유지보수성을 향상시킨다. 제품 객체 생성 방식을 변경해야 할 때, 관련 코드를 여러 클라이언트에서 찾아 수정하는 대신, 해당 구체 팩토리 클래스만 수정하면 된다. 이는 코드 중복을 줄이고 변경의 영향을 국소화한다.

추상 팩토리 패턴은 새로운 제품군을 추가하기 어렵다. 새로운 종류의 제품을 지원하려면 추상 팩토리 인터페이스를 변경해야 하며, 이는 모든 구체 팩토리 클래스와 이를 사용하는 클라이언트 코드에 영향을 미친다. 이는 개방-폐쇄 원칙을 위반하는 것으로, 확장에는 열려 있지만 변경에는 닫혀 있어야 하는 객체지향 설계 원칙과 충돌한다.

패턴의 구현 복잡성이 증가한다. 관련 객체들을 생성하는 인터페이스를 제공하기 위해 많은 수의 새로운 인터페이스와 클래스들이 도입된다. 이는 단순한 객체 생성 작업에 비해 코드베이스의 규모와 구조적 복잡성을 크게 늘린다. 특히 작은 규모의 애플리케이션이나 제품군의 종류가 고정된 경우에는 과도한 설계가 될 수 있다.

구체 팩토리 객체가 생성하는 구체 제품 클래스들을 클라이언트가 미리 알고 있어야 한다. 클라이언트는 팩토리 메서드 패턴을 통해 제품을 생성하지만, 어떤 구체 클래스의 인스턴스가 반환되는지에 대한 지식이 암묵적으로 필요하다. 이는 제품 객체의 구체적인 타입에 대한 의존성을 완전히 제거하지 못함을 의미한다.

추상 팩토리 패턴을 구현하는 일반적인 단계는 다음과 같다. 먼저, 생성할 제품군의 공통 인터페이스 또는 추상 클래스를 정의한다. 예를 들어, '버튼'과 '체크박스'라는 서로 다른 제품군이 있다면, Button과 CheckBox라는 추상 타입을 각각 만든다.

다음으로, 각 구체적인 제품군(예: Windows 스타일, macOS 스타일)에 대해 위에서 정의한 추상 타입들을 구현한 구체 클래스들을 생성한다. 예를 들어 WindowsButton, MacButton, WindowsCheckBox, MacCheckBox 클래스들을 만든다. 이후, 이 제품군들을 생성할 추상 팩토리 인터페이스를 정의한다. 이 인터페이스는 각 제품 타입별 생성 메서드(예: createButton(), createCheckBox())를 선언한다.

마지막으로, 각 구체적인 제품군에 해당하는 구체 팩토리 클래스를 구현한다. WindowsFactory와 MacFactory 같은 클래스가 추상 팩토리 인터페이스를 구현하여, 자신의 스타일에 맞는 구체 제품 객체(예: WindowsButton 객체)를 반환하도록 각 생성 메서드를 작성한다. 클라이언트 코드는 구체 팩토리 타입에 의존하지 않고 추상 팩토리 인터페이스만을 통해 제품 객체들을 생성하고 사용한다.

구현 시 고려할 점은 제품군이 추가되거나 변경될 때의 확장성이다. 새로운 스타일(예: Linux 스타일)의 제품군을 추가하려면, 새로운 구체 제품 클래스들과 이를 생성할 새로운 구체 팩토리 클래스 하나만 구현하면 된다. 이는 개방-폐쇄 원칙을 따르는 방식이다. 그러나 새로운 종류의 제품(예: '스크롤바')이 제품군에 추가된다면, 추상 팩토리 인터페이스와 모든 구체 팩토리 클래스를 수정해야 하므로 변경이 어려워진다.

구현 예제는 객체 지향 프로그래밍 언어의 문법적 특성에 따라 다르게 나타난다. 공통적인 개념은 추상 팩토리 인터페이스와 이를 구현하는 구체 팩토리 클래스, 그리고 생성될 제품군에 대한 추상 클래스 또는 인터페이스로 구성된다.

다음은 주요 언어별 구현 예제의 개요이다.

Java 예제에서는 GUIFactory 인터페이스에 createButton()과 createCheckbox() 메서드를 선언한다. WinFactory와 MacFactory 클래스가 이를 구현하여 각각 Windows 스타일과 macOS 스타일의 Button 및 Checkbox 객체를 반환한다. 클라이언트 코드는 특정 팩토리 인스턴스에 의존하지 않고 GUIFactory 인터페이스를 통해 제품을 생성한다.

C++ 예제에서는 유사한 구조를 가지지만, 생성된 제품 객체에 대한 포인터를 반환하며, 사용 후 메모리 해제를 신경 써야 한다. 현대 C++에서는 std::unique_ptr 같은 스마트 포인터를 활용하여 자원 관리 부담을 줄일 수 있다.

Python 예제는 더 간결하다. AbstractFactory 클래스를 정의하거나, 단순히 공통 메서드 시그니처를 기대하는 방식으로 구현한다. ConcreteFactory1 클래스는 create_product_a() 메서드에서 ConcreteProductA1 객체를 반환한다. Python의 동적 특성으로 인해, 제품 객체들이 공통의 베이스 클래스를 명시적으로 상속받지 않아도 기능상 문제가 없을 수 있다.

팩토리 메서드 패턴은 객체 생성을 서브클래스에 위임하는 생성 패턴이다. 이 패턴은 슈퍼클래스에서 객체를 생성하기 위한 인터페이스를 정의하지만, 생성할 객체의 정확한 클래스를 결정하는 것은 서브클래스에 맡긴다. 따라서 클라이언트 코드는 생성될 구체적인 클래스에 대해 알 필요 없이, 공통 인터페이스를 통해 객체를 생성하고 사용할 수 있다.

추상 팩토리 패턴과의 가장 큰 차이는 복잡성과 범위에 있다. 팩토리 메서드 패턴은 단일 제품의 생성을 다루는 반면, 추상 팩토리 패턴은 연관된 또는 의존적인 제품군 전체를 생성하는 방법을 정의한다. 추상 팩토리는 종종 여러 개의 팩토리 메서드로 구현된다. 즉, 추상 팩토리 패턴은 팩토리 메서드 패턴을 구성 요소로 활용하여 더 높은 수준의 추상화를 제공한다.

두 패턴의 관계는 다음 표로 정리할 수 있다.

팩토리 메서드 패턴은 클래스 상속에 의존하는 반면, 추상 팩토리 패턴은 객체 합성을 강조한다. 이는 디자인 패턴의 핵심 원칙 중 하나인 "상속보다는 합성을 선호하라"는 측면에서 추상 팩토리가 더 유연한 구조를 가질 수 있음을 시사한다. 그러나 단일 제품 생성이라는 단순한 요구사항에는 팩토리 메서드 패턴이 더 적합하고 직관적인 해결책이 된다.

빌더 패턴은 복잡한 객체의 생성 과정을 단계별로 분리하여, 동일한 생성 절차에서 서로 다른 표현(구성)을 가진 객체를 만들 수 있게 하는 생성 패턴이다. 이 패턴은 객체의 생성 코드와 표현 코드를 분리하여, 생성 알고리즘은 독립적으로 유지하면서 객체의 내부 표현을 다양하게 변경할 수 있게 한다.

주로 생성해야 할 객체가 많은 선택적 매개변수를 가지거나, 생성 단계에 순서가 존재할 때 적용된다. 예를 들어, HTML 문서 생성기나 복잡한 의식적 인터페이스를 구성하는 GUI 컴포넌트를 만드는 경우에 유용하다. 패턴의 주요 참여자로는 제품을 정의하는 Product, 생성 단계를 선언하는 Builder 인터페이스, 구체적인 생성 단계를 구현하는 ConcreteBuilder, 그리고 생성 과정을 지시하는 Director가 있다.

빌더 패턴과 추상 팩토리 패턴은 모두 복잡한 객체 생성을 다루지만 목적이 다르다. 추상 팩토리 패턴은 연관된 객체 군을 생성하는 데 중점을 두는 반면, 빌더 패턴은 하나의 복합 객체를 단계별로 구성하는 데 중점을 둔다. 또한, 팩토리 메서드 패턴은 서브클래스가 생성할 객체의 클래스를 결정하는 반면, 빌더 패턴은 객체의 복잡한 조립 과정을 추상화한다.

빌더 패턴의 주요 장점은 생성 코드와 표현 코드의 분리, 생성 과정의 세밀한 제어, 그리고 불변성 객체를 만들기 쉽다는 점이다. 단점은 패턴을 적용하기 위해 여러 새로운 클래스(Builder, ConcreteBuilder, Director)를 만들어야 하므로 코드 복잡도가 증가할 수 있다는 점이다.

프로토타입 패턴은 생성 디자인 패턴의 하나로, 새로운 객체를 생성할 때 기존 객체를 복제하는 방식을 사용한다. 이 패턴은 추상 팩토리 패턴이나 팩토리 메서드 패턴과 마찬가지로 객체 생성 과정을 캡슐화하지만, 그 메커니즘이 근본적으로 다르다. 프로토타입 패턴은 특정 클래스에 의존하지 않고, 복제 가능한 프로토타입 인스턴스를 등록해두고 필요할 때 이를 복사하여 새로운 인스턴스를 만든다.

이 패턴의 핵심은 clone 또는 copy 메서드를 정의하는 프로토타입 인터페이스를 두는 것이다. 구체적인 클래스는 이 인터페이스를 구현하여 자신의 복제 로직을 제공한다. 클라이언트는 원하는 객체의 구체적인 클래스를 알 필요 없이, 등록된 프로토타입 객체로부터 복제를 요청하기만 하면 된다. 이 방식은 특히 생성 비용이 큰 객체(예: 데이터베이스에서 복잡한 쿼리 결과를 로드한 객체)나 구성이 매우 복잡한 객체를 생성할 때 유리하다.

추상 팩토리 패턴과 프로토타입 패턴은 함께 사용될 수 있다. 추상 팩토리의 구체적인 팩토리가 프로토타입 객체 컬렉션을 관리하고, 새로운 제품을 생성할 때 이 프로토타입들을 복제하여 반환하는 방식이다[4]. 이렇게 하면 팩토리마다 새로운 서브클래스를 만들 필요 없이, 단순히 다른 프로토타입 객체를 구성함으로써 새로운 제품 군을 쉽게 정의할 수 있다.