Creational Patterns ( 생성 패턴 )

These design patterns provides way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case. 

생성패턴은 객체의 생성로직을 숨기고 new 명령어를 통하지 않고 객체를 생성하는 방법들을 제공한다. 이는 특정 상황에서 어떤 방법으로 객체를 생성해야할지를 결정하는데 있어서 유연성을 제공한다. 

 Structural Patterns ( 구조적 패턴 )

These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities. 

구조적 패턴들은 클래스와 객체의 구성에 관여한다.

 Behavioral Patterns ( 행위적 패턴 )

These design patterns are specifically concerned with communication between objects.

이 패턴들은 객체들 사이의 커뮤니케이션에 관심을 가진다.

오늘 살펴볼  Abstract Factory 패턴은 Creational 패턴에 속한다.  

Abstract Factory Pattern Structure

패턴의 목적 ( Intent ) : 

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

추상 팩토리 패턴은 구상클래스를 명시하지 않아도 연관있거나 의존적인 객체의 그룹을 생성하기위한 인터페이스를 제공하는 패턴이다.

참고로 Factory는 싱글턴 패턴을 사용하는 것이 일반적이다. ( 동일한 제품을 생산하는 두개의 다른 공장을 하나의 애플리케이션에서 가지고 있을 필요는 없기 때문이다. ) 

패턴이 나오게 된 동기 ( Motivation ) :

 GOF의 디자인 패턴에서 예로 든 내용을 좀 꾸며서 얘기해보겠다.  

자, 우리 회사는 여러개의 위젯을 제공하는데 위젯마다 Look and Feel ( 이하 LNF )이 다르다. 지금까지 Window와 ScrollBar를 내가 만들어 놨는데 신입개발자가 이를 이용해서 위젯을 만들 수 있도록 해주고 싶다. 그래서 나는 WidgetFactory를 만들어 신입개발자가 사용할 수 있도록 할 것이다. 내가 만든 Window와 ScrollBar의 구상 클래스를 몰라도 WidgetFactory에서 알아서 생성해 줄 테니 신입개발자는 WidgetFactory 사용법만 알면 되겠지. 신입개발자가 PMWidget을 만들고 싶으면 PMWidgetFactory를 이용하면되고 MotifWidget을 만들고 싶으면 MotifWidgetFactory를 사용하면 되는거다. 

유용성 ( Applicability ) :

Use the Abstract Factory pattern when

· a system should be independent of how its products are created, composed, and represented.
· a system should be configured with one of multiple families of products.  

· a family of related product objects is designed to be used together, and you need to enforce this constraint.
· you want to provide a class library of products, and you want to reveal just their interfaces, not their implementations.

등장 인물 ( Participants ) :

· AbstractFactory (WidgetFactory)
o declares an interface for operations that create abstract product objects.
· ConcreteFactory (MotifWidgetFactory, PMWidgetFactory)
o implements the operations to create concrete product objects.
· AbstractProduct (Window, ScrollBar)
o declares an interface for a type of product object.
· ConcreteProduct (MotifWindow, MotifScrollBar)
o defines a product object to be created by the corresponding concrete factory.
o implements the AbstractProduct interface.
· Client
o uses only interfaces declared by AbstractFactory and AbstractProduct classes.

원리 ( Collaborations ) :

패턴 사용의 장단점 ( Consequences ): 

The Abstract Factory pattern has the following benefits and liabilities:

1. It isolates concrete classes. The Abstract Factory pattern helps you control the classes of objects that an application creates. Because a factory encapsulates the responsibility and the process of creating product objects, it isolates clients from implementation classes. Clients manipulate instances through their abstract interfaces. Product class names are isolated in the implementation of the concrete factory; they do not appear in client code.  

2. It makes exchanging product families easy. The class of a concrete factory appears only once in an application—that is, where it's instantiated. This makes it easy to change the concrete factory an application uses. It can use different product configurations simply by changing the concrete factory. Because an abstract factory creates a complete family of products, the whole product family changes at once. In our user interface example, we can switch from Motif widgets to Presentation Manager widgets simply by switching the corresponding factory objects and recreating the interface.

3. It promotes consistency among products. When product objects in a family are designed to work together, it's important that an application use objects from only one family at a time. AbstractFactory makes this easy to enforce.

4. Supporting new kinds of products is difficult. Extending abstract factories to produce new kinds of Products isn't easy. That's because the AbstractFactory interface fixes the set of products that can be created. Supporting new kinds of products requires extending the factory interface, which involves changing the AbstractFactory class and all of its subclasses. 

새 로운 종류의 제품을 생산하는 것이 힘들다. 새로운 제품을 만들기 위해 AbstractFactory가 변경이 되면 이를 구현하는 구상클래스(concrete classes)들이 모두 변경되야 하기 때문이다. 이런 문제를 보완하기 위해서 Prototype-based Factory ( 프로토타입 패턴을 이용한 Factory )를 이용하는 방법도 있다.  

관련 패턴들 : 

 AbstractFactory classes are often implemented with factory methods (Factory Method), but they can also be implemented using Prototype.
A concrete factory is often a singleton.

추가 정보 :     

• Sometimes creational patterns are competitors: there are cases when either Prototype or Abstract Factory could be used profitably. At other times they are complementary: Abstract Factory might store a set of Prototypes from which to clone and return product objects, Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementation.
• Abstract Factory, Builder, and Prototype define a factory object that's responsible for knowing and creating the class of product objects, and make it a parameter of the system. Abstract Factory has the factory object producing objects of several classes. Builder has the factory object building a complex product incrementally using a correspondingly complex protocol. Prototype has the factory object (aka prototype) building a product by copying a prototype object.
• Abstract Factory classes are often implemented with Factory Methods, but they can also be implemented using Prototype.
• Abstract Factory can be used as an alternative to Facade to hide platform-specific classes.
• Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.
• Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.

출처 :  http://sourcemaking.com/design_patterns/abstract_factory

Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )