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.

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

오늘 살펴볼  Interpreter 패턴은 Behavioral 패턴에 속합니다. 

Interpreter Pattern Structure

패턴의 목적 ( Intent ) :  

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

   
A class of problems occurs repeatedly in a well-defined and well-understood domain. If the domain were characterized with a "language", then problems could be easily solved with an interpretation "engine".

GoF의 디자인 패턴에서는 아래와 같은 예제가 나옵니다.

expression ::= literal | alternation | sequence | repetition |
                   '(' expression ')'

유용성 ( Applicability ) :

등장 인물 ( Participants ) :

원리 ( Collaborations ) :  

관련 패턴들 :  

• Considered in its most general form (i.e. an operation distributed over a class hierarchy based on the Composite pattern), nearly every use of the Composite pattern will also contain the Interpreter pattern. But the Interpreter pattern should be reserved for those cases in which you want to think of this class hierarchy as defining a language.
• Interpreter can use State to define parsing contexts.
• The abstract syntax tree of Interpreter is a Composite (therefore Iterator and Visitor are also applicable).
• Terminal symbols within Interpreter's abstract syntax tree can be shared with Flyweight.
• The pattern doesn't address parsing. When the grammar is very complex, other techniques (such as a parser) are more appropriate.

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

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

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.

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

오늘 살펴볼  Observer 패턴은 Behavioral 패턴에 속합니다. 

옵저버라고 하니까 10년전에 스타크래프트에서 나왔던 옵저버가 생각이 나네요. cloaking상태로 여기저기 맵을 뒤지고 다녔던 녀석이죠. HP는 어찌나 적은지 한방에 그냥 펑 터져서 죽어버리던 녀석이었죠 ㅎㅎ.

이 옵저버 패턴은 한 객체의 상태를 지켜보고 있다가 이 객체의 상태가 변경이 되면 이 객체의 상태에 의존적인 다른 객체들의 상태를 자동으로 업데이트할 수 있게끔 해주는 패턴이라고 합니다.  

아래에서 좀 더 자세히 알아보도록 하겠습니다.

Observer Pattern Structure

패턴의 목적 ( Intent ) :  

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

유용성 ( Applicability ) :

등장 인물 ( Participants ) :

추가 정보 :       

• Chain of Responsibility, Command, Mediator, and Observer, address how you can decouple senders and receivers, but with different trade-offs. Chain of Responsibility passes a sender request along a chain of potential receivers. Command normally specifies a sender-receiver connection with a subclass. Mediator has senders and receivers reference each other indirectly. Observer defines a very decoupled interface that allows for multiple receivers to be configured at run-time.
• Mediator and Observer are competing patterns. The difference between them is that Observer distributes communication by introducing "observer" and "subject" objects, whereas a Mediator object encapsulates the communication between other objects. We've found it easier to make reusable Observers and Subjects than to make reusable Mediators.
• On the other hand, Mediator can leverage Observer for dynamically registering colleagues and communicating with them.

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

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

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.

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

오늘 살펴볼  Mediator 패턴은 Behavioral 패턴에 속합니다. 

Mediator Pattern Structure

패턴의 목적 ( Intent ) :  

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

    We want to design reusable components, but dependencies between the potentially reusable pieces demonstrates the "spaghetti code" phenomenon. 개발자들은 보통 재사용 가능한 컴포넌트들을 만들고 싶어하지만 잠재적으로 재사용가능한 코드들의 의존성이 일명 "스파게티 코드"를 발생시키게 됩니다. 스파게티 코드라는 것은 거미줄처럼 뒤죽박죽 의존성이 존재하는 것을 의미합니다.

유닉스나 리눅스 시스템에 있는 사용자 퍼미션 시스템을 예로 들어보겠습니다. 한 사용자는 여러 그룹에 속해있을 수 있으며 한 그룹은 여러 사용자를 가질 수 있습니다. 아래 그림 처럼 말이죠. 

위 시스템을 구현한다고 해보자구요. 그럼 User 객체들과 Group객체들 사이에 연결고리가 있겠죠? 그 연결고리 때문에 User객체나 Group객체가 변경될 때 서로 영향을 미치게 될겁니다. 그러면 둘 사이의 관계만을 정의하는 객체를 따로 만들면 어떨 까요? User객체나 Group객체가 변경되어도 서로에게 영향을 미치게 될 일이 사라지게 됩니다. 또한, 수많은 관계들을 쉽게 관리할 수 있게 될 뿐아니라 수정하는 일도 쉬워질 겁니다. 

여기서 관계를 정의하는 객체를 중재자 객체라고 생각할 수 있습니다. 중재자 객체는 다음 역할들을 수행합니다. 

1. encapsulates all interconnections
2. acts as the hub of communication
3. is responsible for controlling and coordinating the interactions of its clients
4. promotes loose coupling by keeping objects from referring to each other explicitly

유용성 ( Applicability ) :

등장 인물 ( Participants ) :

추가 정보 :      

• Chain of Responsibility, Command, Mediator, and Observer, address how you can decouple senders and receivers, but with different trade-offs. Chain of Responsibility passes a sender request along a chain of potential receivers. Command normally specifies a sender-receiver connection with a subclass. Mediator has senders and receivers reference each other indirectly. Observer defines a very decoupled interface that allows for multiple receivers to be configured at run-time.
• Mediator and Observer are competing patterns. The difference between them is that Observer distributes communication by introducing "observer" and "subject" objects, whereas a Mediator object encapsulates the communication between other objects. We've found it easier to make reusable Observers and Subjects than to make reusable Mediators.
• On the other hand, Mediator can leverage Observer for dynamically registering colleagues and communicating with them.
• Mediator is similar to Facade in that it abstracts functionality of existing classes. Mediator abstracts/centralizes arbitrary communication between colleague objects, it routinely "adds value", and it is known/referenced by the colleague objects (i.e. it defines a multidirectional protocol). In contrast, Facade defines a simpler interface to a subsystem, it doesn't add new functionality, and it is not known by the subsystem classes (i.e. it defines a unidirectional protocol where it makes requests of the subsystem classes but not vice versa).

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

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

디자인 패턴에 대해서 한번 훑어보긴 했었는데 다시한번 복습하는 차원에서 하나하나 정리하는 시간을 갖고 싶었다. 그리고 오늘은 그 첫째 날.

오 늘 함께 볼 디자인패턴은 Iterator 패턴이다. 내용의 대부분은 GoF의 디자인패턴 책에서 발췌를 하게될 것임을 밝힌다. 그리고 영문을 한글로 번역을 하게 될텐데 전문번역가가 아니므로 한글 번역본이 이해가 안간다고 느끼면 영문 원본을 읽어보시길 권유한다.

그럼 시작해 볼까?

우선 GoF의 디자인 패턴은 아래와 같이 크게 3가지 종류로 분류된다.

 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.

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

이제 살펴볼 Iterator 패턴은 Behavioral 패턴에 속한다. 

Iterator는 자바의 Iterator와 같은 것을 말한다. 사전적 의미로 "반복자"라고 불리는 iterator는 자바의 경우 collection객체에서 사용이 된다. 오라클에서 제공하는 Iterator에 대한 정보는 이곳에서 확인하면된다. 이처럼 앞으로 살펴볼 모든 패턴들은 그 이름에서 이 패턴이 어떤 패턴인지 파악할 수가 있다.

Iterator Pattern Structure

패턴의 목적 :
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Iterator 패턴의 목적은 aggregate object ( ex. List )를 순차적으로 액세스 할 수 있는 방법을 제공하는 것이다. 물론 이 과정에서 개발자는 object가 어떤식으로 구현이 되어있는지는 알 필요가 없으므로 object의 구현부를 노출시키지 않는다.

유용성 ( Applicability ) :

· to access an aggregate object's contents without exposing its internal representation.

내부 구현을 노출시키지 않으면서 집약 객체의 내용물에 접근하고자 할 때
· to support multiple traversals of aggregate objects.

집약(집합) 객체들에 대해 다양한 탐색경로(?)를 지원하고자 할 때
· to provide a uniform interface for traversing different aggregate structures (that is, to support polymorphic iteration).

다른 집약(집합)구조들을 탐색하기위한 통일된 인터페이스를 제공하고자 할 때 (즉, 다형적 iteration을 지원하고자 할 때 )

등장 인물 :
· Iterator
o defines an interface for accessing and traversing elements.
· ConcreteIterator
o implements the Iterator interface.
o keeps track of the current position in the traversal of the aggregate.
· Aggregate
o defines an interface for creating an Iterator object.
· ConcreteAggregate
o implements the Iterator creation interface to return an instance of the proper ConcreteIterator.

장단점 :
1. It supports variations in the traversal of an aggregate.Complex aggregates
may be traversed in many ways. For example, code generation and semantic checking involve traversing parse trees. Code generation may traverse the parse tree inorder or preorder.Iterators make it easy to change the traversal algorithm: Just replace the iterator instance with a different
one. You can also define Iterator subclasses to support new traversals.
2. Iterators simplify the Aggregate interface.Iterator's traversal interface obviates the need for a similar interface in Aggregate, thereby simplifying the aggregate's interface.
3. More than one traversal can be pending on an aggregate.An iterator keeps track of its own traversal state. Therefore you can have more than one traversal in progress at once.

관련 패턴들 : 

Composite : Iterators are often applied to recursive structures such as Composites.
Factory Method : Polymorphic iterators rely on factory methods to instantiate theappropriate Iterator subclass.
Memento is often used in conjunction with the Iterator pattern. An iterator can use a memento to capture the state of an iteration. The iterator stores the memento internally. 

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

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.

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

오늘 살펴볼  Composite 패턴은 Structural 패턴에 속한다.  

Composite Pattern Structure

A typical Composite object structure might look like this:

패턴의 목적 ( Intent ) : 

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

컴 포지트 패턴은 객체들의 관계를 트리 구조로 구성하여 부분-전체 계층을 표현하는 패턴으로, 사용자가 단일 객체와 복합 객체 모두 동일하게 다루도록 하는 패턴이다. 따라서, {객체의 그룹}과 {하나의 객체}가 동일한 행위를 할 때 적용되야 하며, 또한 트리구조를 생성할 때 사용될 수 있다. 

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

그 래픽 툴은 사용자들로 하여금 간단한 컴포넌트 ( ex. 선, 사각형, 문자, 그림 등등 )부터 복잡한 컴포넌트 ( ex. 글씨가 들어간 사각형 )에 이르기까지 간단하게 표현할 수 있도록 해준다. 이를 간단히 구현하자면 각각의 클래스를 정의하는 것이다. Line클래스, Rectangle 클래스를 각각 정의해서 가져다가 쓰면 되는데 단순히 이렇게 구현을 하면 나중에 큰 문제가 발생 할 수 있다. 왜냐하면 프리미티브 객체와 컨테이너 객체를 다르게 다루어야 하기 때문이다. 이게 무슨 소리냐 하면, 그림판에서 하나의 직선을 그었다고 하자. 이 직선은 시작점과 끝점 좌표를 가지고 있는 하나의 객체겠지? 그런데 또다른 직선을 그었다. 두번째 직선 역시 시작점과 끝점 좌표를 가지고 있겠지. 그런데 이 두개를 한꺼번에 저장하려면 두개의 직선 객체를 가지고있는 또다른 wrapper 클래스가 있어야 할 것이다. 그런데 직선이 몇개가 될지 누가 아냐? 그리는 사람이 몇개를 그릴지는 아무도 모르잖아? 그래서 이런 식으로 접근하다가는 평생해도 제대로된 그래픽 툴을 못 만들 것이다. 그래서 나온 것이 바로 이 컴포지트 패턴인 것이다. 아래 다이어그램을 보자.

위 다이어그램은 직선, 사각형, 문자, 그림을 모두 그래픽 객체를 구현하는 클래스로 만들어 버리고 각 그래픽 클래스는 자식으로 그래픽 클래스를 가질 수 있도록 했다. 그래픽 클래스가 그래픽 클래스를 자식으로 갖는다? 이해가 되는가? 예를 들어보자.

내 가 어제 하나의 그림을 그렸다. 이 그림은 사각형과 직선 그리고 문자를 가지고 있다. 그리고 오늘 나는 두번째 그림을 그리면서 어제 그린 그림과 또 다른 선, 사각형을 그려넣었다. 이것을 다이어그램으로 표현한 것이 아래 그림이다.

유용성 ( Applicability ) :

 Use the Composite pattern when
· you want to represent part-whole hierarchies of objects.
· you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly.

등장 인물 ( Participants ) :

· Component (Graphic)
o declares the interface for objects in the composition.
o implements default behavior for the interface common to all classes, as appropriate.
o declares an interface for accessing and managing its child components.
o (optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate.
· Leaf (Rectangle, Line, Text, etc.)
o represents leaf objects in the composition. A leaf has no children.
o defines behavior for primitive objects in the composition.
· Composite (Picture) 

o defines behavior for components having children.
o stores child components.
o implements child-related operations in the Component interface.
· Client
o manipulates objects in the composition through the Component interface.

원리 ( Collaborations ) :

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

The Composite pattern

· defines class hierarchies consisting of primitive objects and composite objects. Primitive objects can be composed into more complex objects, which in turn can be composed, and so on recursively. Wherever client code expects a primitive object, it can also take a composite object.  

· makes the client simple. Clients can treat composite structures and individual objects uniformly. Clients normally don't know (and shouldn't care) whether they're dealing with a leaf or a composite component. This simplifies client code, because it avoids having to write tag-and-case-statement-style functions over the classes that define the composition.
· makes it easier to add new kinds of components. Newly defined Composite or Leaf subclasses work automatically with existing structures and client code. Clients don't have to be changed for new Component classes.
· can make your design overly general. The disadvantage of making it easy to add new components is that it makes it harder to restrict the components of a composite. Sometimes you want a composite to have only certain components. With Composite, you can't rely on the type system to enforce those constraints for you. You'll have to use run-time checks instead.

관련 패턴들 : 

 Often the component-parent link is used for a Chain of Responsibility.
Decorator is often used with Composite. When decorators and composites are used together, they will usually have a common parent class. So decorators will have to support the Component interface with operations like Add, Remove, and GetChild.
Flyweight lets you share components, but they can no longer refer to their parents.
Iterator can be used to traverse composites.
Visitor localizes operations and behavior that would otherwise be distributed across Composite and Leaf classes.

추가 정보 :

• Composite and Decorator have similar structure diagrams, reflecting the fact that both rely on recursive composition to organize an open-ended number of objects.
• Composite can be traversed with Iterator. Visitor can apply an operation over a Composite. Composite could use Chain of Responsibility to let components access global properties through their parent. It could also use Decorator to override these properties on parts of the composition. It could use Observer to tie one object structure to another and State to let a component change its behavior as its state changes.
• Composite can let you compose a Mediator out of smaller pieces through recursive composition.
• Decorator is designed to let you add responsibilities to objects without subclassing. Composite's focus is not on embellishment but on representation. These intents are distinct but complementary. Consequently, Composite and Decorator are often used in concert.
• Flyweight is often combined with Composite to implement shared leaf nodes.

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

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

http://www.journaldev.com/1535/composite-design-pattern-in-java-example-tutorial 

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.

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

오늘 살펴볼  Proxy 패턴은 Structural 패턴에 속한다.  

프 록시 패턴은 네트워킹을 공부해본 사람이라면 이해하기가 쉬울 것이다. 프록시가 뭔지를 알테니까 말이다. 여기서 말하는 프록시란 프록시 서버에서 말하는 그것과 동일한 개념이다. 일종의 중간연결자 역할을 하는 클래스를 만들어서, 요청이 들어오면 최초 요청일 경우 새로 생성하고 생성된 객체를 응답으로 보내고, 두번째 요청부터는 기존에 생성했던 것을 응답으로 보내는 것이다.

이해가 잘 안간다면 좀 더 자세히 알아보자. 

Proxy Pattern Structure

우선 이 클래스 다이어그램부터 이해를 해보도록 하자. 여기서 중요한 것은 RealSubject와 Proxy 그리고 Subject사이의 관계이다. 클라이언트는 Subject객체의 Request()를 호출하고 Subject객체를 받는다. RealSubject와  Proxy는 Subject를 상속하는 클래스들인데 Proxy클래스의 Request()는 경우에 따라 RealSubject의 Request()를 호출한다. RealSubject의 Request()에서는 클라이언트가 원하는 Subject객체를 반환한다.  

패턴의 목적 ( Intent ) :  

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

워 드프로그램에서 사진파일을 넣게되면 로딩이 느려지는 현상이 발생할 때가 있었다. 지금이야 워낙 컴퓨터 사양이 좋아져서 그런일을 많이 보지는 못하지만 사진파일 사이즈역시 좋은 화질인 경우 상당한 사이즈를 자랑하기 때문에 무시할 수 없다. 이런 경우 페이지를 이동할 때마다 디스크에 있는 이미지 파일을 계속 요청하는 것이 아니라 한번만 요청하여 프록시에 가지고 있다가 다시 요청이 들어오면 프록시에서 이미지를 가져와서 디스플레이 해주는 방식이 필요하게 된 것이다. 이런식으로 속도의 향상을 꿰한것이다. 아래 그림은 디스크에 있는 이미지 파일에서 데이타를 읽어와서 메모리에 상주하는 프록시에 넣고 문서에서 이에 접근하는 것을 보여주고있다.

위에서 봤던 클래스 다이어그램에 문서프로그램의 예를 적용시켜 본 것이다. ImageProxy의 우측을 보면 image가 0인지를 판별하고 0일경우 Image를 가져와서 보여준다는 것을 알려주는 간략한 소스가 보인다.

유용성 ( Applicability ) :

등장 인물 ( Participants ) :

원리 ( Collaborations ) :

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

관련 패턴들 : 

추가 정보 :   

• Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced interface.
• Decorator and Proxy have different purposes but similar structures. Both describe how to provide a level of indirection to another object, and the implementations keep a reference to the object to which they forward requests.

프록시 패턴을 사용한 간단한 예제입니다.

interface Image {
    public void displayImage();
}
 
//on System A 
class RealImage implements Image {
    private String filename;
    public RealImage(String filename) { 
        this.filename = filename;
        loadImageFromDisk();
    }
 
    private void loadImageFromDisk() {
        System.out.println("Loading   " + filename);
    }
 
    public void displayImage() { 
        System.out.println("Displaying " + filename); 
    }
}
 
//on System B 
class ProxyImage implements Image {
    private String filename;
    private Image image;
 
    public ProxyImage(String filename) { 
        this.filename = filename; 
    }
    public void displayImage() {
        if (image == null)
        {
           image = new RealImage(filename);
        } 
        image.displayImage();
    }
}
 
class ProxyExample {
    public static void main(String[] args) {
        Image image1 = new ProxyImage("HiRes_10MB_Photo1");
        Image image2 = new ProxyImage("HiRes_10MB_Photo2");     
 
        image1.displayImage(); // loading necessary
        image2.displayImage(); // loading necessary
        image1.displayImage(); // loading unnecessary
        image2.displayImage(); // loading unnecessary
    }
}

또 다른 목적( 리눅스에서 권한에 따라 명령어 실행을 막거나 통과시키는)으로 사용된 프록시 패턴의 예제는 아래 링크에서 보실 수 있습니다.

http://www.journaldev.com/1572/proxy-design-pattern-in-java-example-tutorial

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

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

 http://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9D%EC%8B%9C_%ED%8C%A8%ED%84%B4

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.

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

오늘 살펴볼  Decorator 패턴은 Structural 패턴에 속한다.  이 패턴은 컴포지트 패턴과 비슷한 다이어그램을 가지고 있다. 

Decorator Pattern Structure

패턴의 목적 ( Intent ) : 

 Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

 동적으로 객체에 책임(꾸밈)을 추가한다. 데코레이터는 기능을 확장하기 위한 subclassing이 아닌 다른 유동적인 방법을 제공한다. 

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

일반적으로 간단한 프로젝트가 아닌 이상 하나의 클래스 내에서 모든 것을 해결하는 일은 거의 없다. 유지보수를 위해서라도 기능별로 클래스를 나누게 되는데 데코레이터 패턴도 이런 식의 생각에서 나오게 된 것이다. 그래서 상속을 사용하게 되기도 하는데 이는 매우 기본적인 방법이며 flexible하지 않고 정적이다. 따라서 동적으로 기능확장이 용이하도록 한 것이 바로 이 데코레이터 패턴이다. 아래 그림은 TextView에 ScrollDecorator와 BorderDecorator를 이용하여 책임(꾸밈)을 추가한 결과이다.

유용성 ( Applicability ) :

Use Decorator

데코레이터 패턴은 아래와 같은 상황에서 유용하다.

· to add responsibilities to individual objects dynamically and transparently, that is, without affecting other objects.

다른 객체에 영향을 주지 않고 동적으로 투명하게 독립적인 객체들을 추가할 때
· for responsibilities that can be withdrawn.

철회가 가능한 책임(꾸밈)을 추가하고 싶을 때
· when extension by subclassing is impractical. Sometimes a large number of independent extensions are possible and would produce an explosion of subclasses to support every combination. Or a class definition may be hidden or otherwise unavailable for subclassing. 

등장 인물 ( Participants ) :

· Component (VisualComponent)
o defines the interface for objects that can have responsibilities added to them dynamically.

동적으로 추가되는 책임을 가질 수 있는 객체를 위한 인터페이스를 정의한다.
· ConcreteComponent (TextView)
o defines an object to which additional responsibilities can be attached.

추가적인 책임을 가질 수 있는 객체를 정의한다.
· Decorator
o maintains a reference to a Component object and defines an interface that conforms to Component's interface.

이 패턴의 메인이다. 컴포넌트 객체의 레퍼런스를 가지고 있으며, 컴포넌트와 조화를 이루는 인터페이스를 정의한다.
· ConcreteDecorator (BorderDecorator, ScrollDecorator)
o adds responsibilities to the component.

컴포넌트에 책임을 부과한다. 

원리 ( Collaborations ) :

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

The Decorator pattern has at least two key benefits and two liabilities:

1. More flexibility than static inheritance. 정적인 상속보다 훨씬 유동적이다. The Decorator pattern provides a more flexible way to add responsibilities to objects than can be had with static (multiple) inheritance. With decorators, responsibilities can be added and removed at run-time simply by attaching and detaching them. In contrast, inheritance requires creating a new class for each additional responsibility (e.g., BorderedScrollableTextView, BorderedTextView). This gives rise to many classes and increases the complexity of a system.
Furthermore, providing different Decorator classes for a specific Component class lets you mix and match responsibilities.
Decorators also make it easy to add a property twice. For example, to give a TextView a double border, simply attach two BorderDecorators. Inheriting from a Border class twice is error-prone at best.

2. Avoids feature-laden classes high up in the hierarchy. Decorator offers a pay-as-you-go approach to adding responsibilities. Instead of trying to support all foreseeable features in a complex, customizable class, you can define a simple class and add functionality incrementally with Decorator objects. Functionality can be composed from simple pieces. As a result, an application needn't pay for features it doesn't use. It's also easy to define new kinds of Decorators independently from the classes of objects
they extend, even for unforeseen extensions. Extending a complex class tends to expose details unrelated to the responsibilities you're adding.

3. A decorator and its component aren't identical. A decorator acts as a transparent enclosure. But from an object identity point of view, a decorated component is not identical to the component itself. Hence you shouldn't rely on object identity when you use decorators.

4. Lots of little objects. A design that uses Decorator often results in systems composed of lots of little objects that all look alike. The objects differ only in the way they are interconnected, not in their class or in the value of their variables. Although these systems are easy to customize by those who understand them, they can be hard to learn and debug. 

관련 패턴들 : 

Adapter : A decorator is different from an adapter in that a decorator only changes an object's responsibilities, not its interface; an adapter will give an object a completely new interface. 

 Composite : A decorator can be viewed as a degenerate composite with only one component. However, a decorator adds additional responsibilities—it isn't intended for object aggregation.
Strategy : A decorator lets you change the skin of an object; a strategy lets you change the guts. These are two alternative ways of changing an object.

추가 정보 :  

• Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced interface.
• Adapter changes an object's interface, Decorator enhances an object's responsibilities. Decorator is thus more transparent to the client. As a consequence, Decorator supports recursive composition, which isn't possible with pure Adapters.
• Composite and Decorator have similar structure diagrams, reflecting the fact that both rely on recursive composition to organize an open-ended number of objects.
• A Decorator can be viewed as a degenerate Composite with only one component. However, a Decorator adds additional responsibilities - it isn't intended for object aggregation.
• Decorator is designed to let you add responsibilities to objects without subclassing. Composite's focus is not on embellishment but on representation. These intents are distinct but complementary. Consequently, Composite and Decorator are often used in concert.
• Composite could use Chain of Responsibility to let components access global properties through their parent. It could also use Decorator to override these properties on parts of the composition.
• Decorator and Proxy have different purposes but similar structures. Both describe how to provide a level of indirection to another object, and the implementations keep a reference to the object to which they forward requests.
• Decorator lets you change the skin of an object. Strategy lets you change the guts.
  

• Decorator pattern is helpful in providing runtime modification abilities and hence more flexible. Its easy to maintain and extend when the number of choices are more.
• The disadvantage of decorator pattern is that it uses a lot of similar kind of objects (decorators).
  데코레이터 패턴의 단점은 유사한 데코레이터 객체가 많아질 수 있다는 점이다.
  
• Decorator pattern is used a lot in Java IO classes, such as FileReader, BufferedReader etc.
  데코레이터 패턴은 FileReader나 BufferedReader와 같은 Java IO 클래스들에서 많이 사용되고 있다.
  

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

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

http://www.journaldev.com/1540/decorator-pattern-in-java-example-tutorial

실생활을 예로 든 좋은 예제는 아래에서 확인하기 바란다.

http://warmz.tistory.com/757

 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.

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

오늘 살펴볼  Adapter 패턴은 Structural 패턴에 속한다.  

어 댑터가 뭐냐? 우리가 맨날 쓰는 그 어댑터가 바로 지금 말하고자하는 어댑터이다. 어댑터의 역할이 뭐냐? 서로 맞물리지 않는 두개의 객체를 연결시켜주는 일을 하는 것이 어댑터의 역할이다. 이 생각을 가지고 아래 내용을 훑어보기 바란다.

Adapter Pattern Structure

 A class adapter uses multiple inheritance to adapt one interface to another:

클래스 어댑터는 하나의 인터페이스를 다른 인터페이스와 연결시키기 위해서 다중상속을 이용한다.

An object adapter relies on object composition:

객체 어댑터는 객체의 구성에 의존한다. ( 뭔 말인지 모르겠다 일단 넘어가자 )

패턴의 목적 ( Intent ) : 

Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

어댑터 패턴의 목적은 클라이언트가 원하는 인터페이스를 제공하기 위해서 클래스의 형태를 변형하는 것이다.(이는 서로 연결을 시켜줌으로써 아웃풋을 변형한다는 의미이지 실제로 변형한다는 의미가 아니다) 어댑터는 서로 맞물리지 않는 인터페이스들을 서로 연결시켜주는 역할을 한다.

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

예 를 들어 이런 경우가 있을 것이다. 고객이 원하는 기능을 구현을 했다고 하자. 이 기능은 인풋으로 A객체를 받아들이고 아웃풋으로 X객체를 던지며 고객이 만든 API와 연결이 된다. 그런데 얼마가 지나서 고객이 인풋으로 Y객체를 달라고 한다. 그런데 전에 만들어 줬던 기능의 일부분만 Y객체를 아웃풋으로 내보내야 한다는 것이다. 당신이라면 어떻게 해결할 것인가? 물론 생각해야할 인자들이 무수히 많을 것이고 그것들에 따라 해결책도 다를 것이다. 여기서는 그 중 하나의 해결책으로 어댑터 패턴을 말하고자 한다. A -> DoSomething -> X 기능을 하는 기능은 여전히 존재해야만 하며 DoSomething -> Y 기능을 추가해야한다. 하지만 이 두가지는 엄연히 동일한 기능을 한다고 가정한다. 어댑터 패턴을 이용해야하니까. 그러면 우리는 A -> DoSomething -> X -> Y 가 될 수 있게끔 X -> Y 기능을 하는 어댑터를 추가하면 된다.

유용성 ( Applicability ) :

Use the Adapter pattern when
· you want to use an existing class, and its interface does not match the one you need.

기존의 클래스를 사용하고 싶지만 내가 필요로 하는 형태가 아닐때
· you want to create a reusable class that cooperates with unrelated or unforeseen classes, that is, classes that don't necessarily have compatible interfaces.

특정 호환성을 가진 클래스가 아닌 광범위한 호환성을 가진 재사용가능한 클래스를 만들고 싶을때
· (object adapter only) you need to use several existing subclasses, but it's impractical to adapt their interface by subclassing every one. An object adapter can adapt the interface of its parent class.

등장 인물 ( Participants ) :

· Target (Shape)o defines the domain-specific interface that Client uses.
· Client (DrawingEditor)o collaborates with objects conforming to the Target interface.
· Adaptee (TextView)o defines an existing interface that needs adapting.
· Adapter (TextShape)o adapts the interface of Adaptee to the Target interface.

원리 ( Collaborations ) : 

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

Class and object adapters have different trade-offs.  

클래스 어댑터와 객체어댑터는 서로의 장단점이 있다.  

A class adapter  

· adapts Adaptee to Target by committing to a concrete Adapter class. As a consequence, a class adapter won't work when we want to adapt a class and all its subclasses.

· lets Adapter override some of Adaptee's behavior, since Adapter is a subclass of Adaptee.
· introduces only one object, and no additional pointer indirection is needed to get to the adaptee.

An object adapter
· lets a single Adapter work with many Adaptees—that is, the Adaptee itself and all of its subclasses (if any). The Adapter can also add functionality to all Adaptees at once.
· makes it harder to override Adaptee behavior. It will require subclassing Adaptee and making Adapter refer to the subclass rather than the Adaptee itself.

관련 패턴들 : 

Bridge has a structure similar to an object adapter, but Bridge has a different intent: It is meant to separate an interface from its implementation so that they can be varied easily and  independently. An adapter is meant to change the interface of an existing object.
Decorator enhances another object without changing its interface. A decorator is thus more transparent to the application than an adapter is. As a consequence, Decorator supports  recursive composition, which isn't possible with pure adapters.
Proxy defines a representative or surrogate for another object and does not change its interface.

추가 정보 :     

• Adapter makes things work after they're designed; Bridge makes them work before they are.
• Bridge is designed up-front to let the abstraction and the implementation vary independently. Adapter is retrofitted to make unrelated classes work together.
• Adapter provides a different interface to its subject. Proxy provides the same interface. Decorator provides an enhanced interface.
• Adapter is meant to change the interface of an existing object. Decorator enhances another object without changing its interface. Decorator is thus more transparent to the application than an adapter is. As a consequence, Decorator supports recursive composition, which isn't possible with pure Adapters.
• Facade defines a new interface, whereas Adapter reuses an old interface. Remember that Adapter makes two existing interfaces work together as opposed to defining an entirely new one.

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

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

 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.

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

오늘 살펴볼  Visitor 패턴은 Behavioral 패턴에 속한다.  

Visitor Pattern Structure

패턴의 목적 ( Intent ) : 

Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

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

Consider a compiler that represents programs as abstract syntax trees. It will need to perform operations on abstract syntax trees for "static semantic" analyses like checking that all variables are defined. Itwill also need to generate code. So it might define operations for type-checking, code optimization, flow analysis, checking for variables being assigned values before they're used, and so on.
Moreover, we could use the abstract syntax trees for pretty-printing, program restructuring, code instrumentation, and computing various metrics of aprogram.
Most of these operations will need to treat nodes that represent assignment statements differently from nodes that represent variables orarithmetic expressions. Hence there will be one class for assignment statements, another for variable accesses, another for arithmetic expressions, and so on. The set of node classes depends on the language being compiled, of course, but it doesn't change much for a given language.

 This diagram shows part of the Node class hierarchy. The problem here is that distributing all these operations across the various node classes leads to a system that's hard to understand, maintain, and change. It will be confusing to have type-checking code mixed with pretty-printing code or flow analysis code. Moreover, adding a new operation usually requires recompiling all of these classes. It would be better if each new operation could be added separately, and the node classes were independent of the operations that apply to them.
We can have both by packaging related operations from each class in a separate object, called a visitor, and passing it to elements of the abstract syntax tree as it's traversed. When an  element "accepts" the visitor, it sends a request to the visitor that encodes the element's class. It also includes the element as an argument. The visitor will then execute the operation for that element —the operation that used to be in the class of the element.

For example, a compiler that didn't use visitors might type-check a procedure by calling the TypeCheck operation on its abstract syntax tree. Each of the nodes would implement TypeCheck by calling TypeCheck on its components (see the preceding class diagram). If the compiler type-checked a procedure using visitors, then it would create a TypeCheckingVisitor object and call the Accept operation on the abstract syntax tree with that object as an argument. Each of the nodes would implement Accept by calling back on the visitor: anassignment node calls
VisitAssignment operation on the visitor, while a variable reference calls VisitVariableReference. What used to be the TypeCheck operation in class AssignmentNode is now the VisitAssignment operation on TypeCheckingVisitor.  

To make visitors work for more than just type-checking, we need an abstract parent class NodeVisitor for all visitors of an abstract syntax tree. NodeVisitor must declare an operation for each node class. An application that needs to compute program metrics will define new subclasses of NodeVisitor and will no longer need to add application-specific code to the node classes. The Visitor pattern encapsulates the operations for each compilation phase in a Visitor associated with that phase.

With the Visitor pattern, you define two class hierarchies: one for the elements being operated on (the Node hierarchy) and one for the visitors that define operations on the elements (the  NodeVisitor hierarchy). You create a new operation by adding a new subclass to the visitor class hierarchy. As long as the grammar that the compiler accepts doesn't change (that is, we don't have to add new Node subclasses), we can add new functionality simply by defining new NodeVisitor subclasses.

유용성 ( Applicability ) :

Use the Visitor pattern when

Visitor 패턴은 이럴때 사용하자!!

· an object structure contains many classes of objects with differing interfaces, and you want to  perform operations on these objects that depend on their concrete classes.
· many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid "polluting" their classes with these operations. Visitor lets you keep related operations together by defining them in one class. When the object structure is shared by many applications, use Visitor to put operations in just those applications that need them.
· the classes defining the object structure rarely change, but you often want to define new operations over the structure. Changing the object structure classes requires redefining the interface to all visitors,which is potentially costly. If the object structure classes change often, then it's probably better to define the operations in those classes.

등장 인물 ( Participants ) :
· Visitor (NodeVisitor)
o declares a Visit operation for each class of ConcreteElement in the object structure. The operation's name and signature identifies the class that sends the Visit request to the visitor. That lets the visitor determine the concrete class of the element being visited. Then the visitor can access the element directly through its particular interface.

· ConcreteVisitor (TypeCheckingVisitor)
o implements each operation declared by Visitor. Each operation implements a fragment of the algorithm defined for the corresponding class of object in the structure. ConcreteVisitor provides the context for the algorithm and stores its local state. This state often accumulates results during the traversal of the structure.

· Element (Node)
o defines an Accept operation that takes a visitor as an argument.

· ConcreteElement (AssignmentNode,VariableRefNode)
o implements an Accept operation that takes a visitor as an argument.

· ObjectStructure (Program)
o can enumerate its elements.
o may provide a high-level interface to allow the visitor to visit its elements.
o may either be a composite (see Composite ) or a collection such as a list or a set.

원리 ( Collaborations ) :

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

Some of the benefits and liabilities of the Visitor pattern are as follows:

1. Visitor makes adding new operations easy. Visitors make it easy to add operations that depend on the components ofcomplex objects. You can define a new operation over an object  structure simply by adding a new visitor.
In contrast, if you spread functionality over many classes, then you must change each class to  define a newoperation.

2. A visitor gathers related operations and separates unrelated ones. Related behavior isn't spread over the classes defining the object structure; it's localized in a visitor. Unrelated sets of behavior are partitioned in their own visitor subclasses. That simplifies both the classes defining the elements and the algorithms defined in the visitors. Any algorithm-specific
data structures can be hidden in thevisitor.

3. Adding new ConcreteElement classes is hard. The Visitor pattern makes it hard to add new subclasses of Element. Each new ConcreteElement gives rise to a new abstract operation on Visitor and a corresponding implementation in every ConcreteVisitor class. Sometimes a default implementation can be provided in Visitor that can be inherited by most of the ConcreteVisitors, but this is the exception rather than the rule. So the key consideration in applying the Visitor pattern is whether you are mostly likely to change the algorithm applied over an object structure or the classes of objects that make up the structure. TheVisitor class hierarchy can be difficult to maintain when new ConcreteElement classes are added frequently. In such cases, it's probably easier just to define operations on the classes that make up the structure. If the Element class hierarchy is stable, but you are continually adding operations or changing algorithms, then the Visitor pattern will help you manage the changes.

4. Visiting across class hierarchies. An iterator (see Iterator ) can visit the objects in a structure as it traverses them by calling their operations. But an iterator can't work across object structures with different types of elements.  

5. Accumulating state. Visitors can accumulate state as they visit each element in the object structure. Without a visitor, this state would be passed as extra arguments to the operations that perform the traversal, or they might appear as global variables.

6. Breaking encapsulation. Visitor's approach assumes that the ConcreteElement interface is powerful enough to let visitors do their job.
As a result, the pattern oftenforces you to provide public operations that
access an element's internal state, which may compromise its encapsulation.

관련 패턴들 : 

Composite :Visitors can be used to apply an operation over an object structure defined by the Composite pattern.
Interpreter :Visitor may be applied to do the interpretation.

추가 정보 :     

• The abstract syntax tree of Interpreter is a Composite (therefore Iterator and Visitor are also applicable).
• Iterator can traverse a Composite. Visitor can apply an operation over a Composite.
• The Visitor pattern is like a more powerful Command pattern because the visitor may initiate whatever is appropriate for the kind of object it encounters.
• The Visitor pattern is the classic technique for recovering lost type information without resorting to dynamic casts.

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

         Design Patterns : Element of Reusab

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.

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

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

빌더 패턴은 팩토리 메소드 또는 추상 팩토리 패턴의 문제점을 해결하기 위해 나온 패턴이다. 팩토리 메소드 또는 추상 팩토리 패턴에는 객체가 많은 속성을 가지고 있을 경우 두가지 중요한 문제가 발생한다. 

첫 째로, 클라이언트가 팩토리 클래스로 넘겨주는 인자가 많아지게되면( 팩토리가 많은 속성을 가지고 있으면 이에 대해 설정을 하기위해 많은 인자를 받아야 한다 ) 잘못된 인자를 넘겨주는 일도 빈번하게 일어날 뿐 아니라 관리하기도 힘들어진다.

둘째로, 몇몇 인자들은 optional일 수 있지만 팩토리 패턴에서는 모든 인자를 넘겨주어야 한다. ( optional 인자는 null로 넘긴다. 이건 귀찮은 일이다. )

빌더 패턴은 단계별로 객체를 생성하고 마지막 객체를 반환하는 메소드를 제공함으로써 위와 같은 문제들을 해결해준다. 

Builder Pattern Structure

패턴의 목적 ( Intent ) : 

 복합 객체의 생성 과정과 표현 방법을 분리하여 동일한 생성 절차에서 서로 다른 표현 결과를 만들 수 있게 하는 패턴

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

예 를들어 RTF포맷 형태의 파일을 ASCIIText나 TeXText 또는 다른 TextWidget의 형태로 변환하는 프로그램을 만든다고 하자. 이때 변환되어 나오는 포맷을 쉽게 추가할 수 있어야 할 것이다. 그래서 나온 패턴이 바로 이 빌더 패턴이다. 위 다이어그램에서 각각의 컨버터 클래스들은 모두 builder이며 reader는 director라 한다. 그리고 변형되어 나오는 Text객체들은 product라고 보면 된다. 

유용성 ( Applicability ) :

등장 인물 ( Participants ) : 

· Builder
o specifies an abstract interface for creating parts of a Product object.
· ConcreteBuilder
o constructs and assembles parts of the product by implementing the Builder interface.
o defines and keeps track of the representation it creates.
o provides an interface for retrieving the product.
· Director
o constructs an object using the Builder interface.
· Product
o represents the complex object under construction. ConcreteBuilder builds the product's internal representation and defines the process by which it's assembled.
o includes classes that define the constituent parts, including interfaces for assembling the parts into the final result.

원리 ( Collaborations ) :

The following interaction diagram illustrates how Builder and Director cooperate with a client.

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

Here are key consequences of the Builder pattern:

1. It lets you vary a product's internal representation. The Builder object provides the director with an abstract interface for constructing the product. The interface lets the builder hide the representation and internal structure of the product. It also hides how the product gets assembled. Because the product is constructed through an abstract interface, all you have to do to change the product's internal representation is define a new kind of builder.

2. It isolates code for construction and representation. The Builder pattern improves modularity by encapsulating the way a complex object is constructed and represented. Clients needn't know anything about the classes that define the product's internal structure; such classes don't appear in Builder's interface. Each ConcreteBuilder contains all the code to create and assemble a particular kind of product. The code is written once; then different Directors can reuse it to build Product variants from the same set of parts.
In the earlier RTF example, we could define a reader for a format other than RTF, say, an SGMLReader, and use the same TextConverters to generate ASCIIText, TeXText, and TextWidget renditions of SGML documents.

3. It gives you finer control over the construction process. Unlike creational patterns that construct products in one shot, the Builder pattern constructs the product step by step under the director's control. Only when the product is finished does the director retrieve it from the builder. Hence the Builder interface reflects the process of constructing the product more than other creational patterns. This gives you finer control over the construction process and consequently the internal structure of the resulting product. 

관련 패턴들 : 

 Abstract Factory is similar to Builder in that it ​constructs too may complex objects. The primary difference is that the Builder pattern focuses on constructing a complex object step by step. Abstract Factory's emphasis is on families of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory pattern is concerned, the product gets returned immediately.
A Composite is what the builder often builds.

추가 정보 :     

• Sometimes creational patterns are complementory: Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.
• 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.
• Builder often builds a Composite.
• 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/builder

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

http://www.journaldev.com/1425/builder-design-pattern-in-java

 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.

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

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

Singleton Pattern Structure

패턴의 목적 ( Intent ) : 

Ensure a class only has one instance, and provide a global point of access to it.

프로그램상에서 단 하나의 인스턴스만을 요구하는 클래스를 만들 필요가 있어서 나온 패턴이다. global하게 access가능한 단 인스턴스 생성이 이 패턴의 목적이다. 

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

목적에서 말한 바와 같이 단 하나의 유일한 객체를 생성하고 이를 사용할 목적으로 나오게 된 패턴이다. 한번 생성하면 그 이후에는 생성된 객체를 이용만 할 뿐이다. 

유용성 ( Applicability ) :

Use the Singleton pattern when
· there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point.
· when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code.

등장 인물 ( Participants ) :

· Singleton
o defines an Instance operation that lets clients access its unique instance. Instance is a class operation (that is, a class method in Smalltalk and a static member function in C++).
o may be responsible for creating its own unique instance.

원리 ( Collaborations ) :

클라이언트들은 이 싱글턴객체에서 제공하는  getter메소드에 의해 오직 혼자만 접근한다.

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

소스 예제 : 

1. 일반적인 경우 ( synchronizing할 필요가 없는 싱글턴 객체의 경우, 싱글쓰레드(single thread) )

// 싱글턴객체가 필요할 때는 인스턴스를 직접 만드는게 아니고 인스턴스를 달라고 요청을 하는 것이다.
public class Singleton {
  private static Singleton uniqueInstance;
 
  private Singleton() {}  // <---  생성자는 private -- 외부에서 new 를 사용하여 객체를 생성할 수 없다...
 
  public static Singleton getInstance() {  // 객체를 생성하는 static 메소드 하나
    if ( uniqueInstance == null ) {        // 이 부분은 객체를 처음 생성할 때만 필요하다~~
      uniqueInstance = new Singleton();
    }
    return uniqueInstance;
  }
}

public class Singleton {
  private static Singleton uniqueInstance;
 
  private Singleton() {}
 
  public static Singleton getInstance() {  
    if ( uniqueInstance == null ) {          // A Thread가 이 코드를 실행할 때
      uniqueInstance = new Singleton();      // B Thread가 객체 생성을 완료하지 않은 경우 
    }                                        // 두개의 객체가 생성될 수 있다.
 
    return uniqueInstance;
  }
}

public class Singleton {
  private static Singleton uniqueInstance;
 
  private Singleton() {}

  // 메소드 자체에 synchronized 를 거는 방법 
  public static synchronized Singleton getInstance() {  
    if ( uniqueInstance == null ) {          
      uniqueInstance = new Singleton(); 
    }                                        
 
    return uniqueInstance;
  }
}

이 방법의 문제점 ) 

C. Double-checking Locking

public class Singleton {
  private volatile static Singleton uniqueInstance;
  
  private Singleton() {}

  // 부분적으로 synchronized를 걸어 객체가 생성된 이후에는 synchronized 구문을 수행하지 않는다.
  public static Singleton getInstance() {
    if ( uniqueInstance == null ) {
      synchronized( Singleton.class ) {
        if ( uniqueInstance == null ) {
          uniqueInstance = new Singleton();
        }
      }
    }
    return uniqueInstance;
  }
}

관련 패턴들 : 

 Many patterns can be implemented using the Singleton pattern. See Abstract Factory, Builder, and Prototype.

추가 정보 :     

• Abstract Factory, Builder, and Prototype can use Singleton in their implementation.
• Facade objects are often Singletons because only one Facade object is required.
• State objects are often Singletons.
• The advantage of Singleton over global variables is that you are absolutely sure of the number of instances when you use Singleton, and, you can change your mind and manage any number of instances.
• The Singleton design pattern is one of the most inappropriately used patterns. Singletons are intended to be used when a class must have exactly one instance, no more, no less. Designers frequently use Singletons in a misguided attempt to replace global variables. A Singleton is, for intents and purposes, a global variable. The Singleton does not do away with the global; it merely renames it.
  싱글턴 패턴은 가장 부적절하게 사용되는 패턴중 하나이다. 원래 싱글턴 패턴의 목적은 더도말고 덜도말고 오로지 단 하나의 인스턴스를 갖기 위함이었으나 일부 개발자들은 단순히 전역변수를 대체하기위해 사용할 때가 있다.
  
• When is Singleton unnecessary? Short answer: most of the time. Long answer: when it's simpler to pass an object resource as a reference to the objects that need it, rather than letting objects access the resource globally. The real problem with Singletons is that they give you such a good excuse not to think carefully about the appropriate visibility of an object. Finding the right balance of exposure and protection for an object is critical for maintaining flexibility.
• Our group had a bad habit of using global data, so I did a study group on Singleton. The next thing I know Singletons appeared everywhere and none of the problems related to global data went away. The answer to the global data question is not, "Make it a Singleton." The answer is, "Why in the hell are you using global data?" Changing the name doesn't change the problem. In fact, it may make it worse because it gives you the opportunity to say, "Well I'm not doing that, I'm doing this" – even though this and that are the same thing.

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

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

http://www.javajigi.net/display/SWD/ch05_singletonpattern

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.

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

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

Prototype Pattern Structure

패턴의 목적 ( Intent ) : 

- Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype. 

하나의 프로토타입 인스턴스를 만들고 필요할때마다 프로토타입 인스턴스를 복사해서 객체를 생성하기 위함 

- Co-opt one instance of a class for use as a breeder of all future instances. 

- The new operator considered harmful.

new 키워드를 이용하는 것이 안좋은 상황일 때 프로토타입 패턴을 이용하자. 

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

객체 생성 비용이 비싼경우 프로토타입 원형을 만들고 클로닝 기법을 이용해서 객체를 쉽게 생성하고자 하기 위함.

유용성 ( Applicability ) :

Use the Prototype pattern when a system should be independent of how its products are created, composed, and represented; and
· when the classes to instantiate are specified at run-time, for example, by dynamic loading; or

클래스의 동적로딩이 필요할 때
· to avoid building a class hierarchy of factories that parallels the class hierarchy of products; or

제품의 클래스 계층과 동일한 팩토리 클래스 계층을 만들고 싶지 않을 때
· when instances of a class can have one of only a few different combinations of state. It may be more convenient to install a corresponding number of prototypes and clone them rather than instantiating the class manually, each time with the appropriate state.

등장 인물 ( Participants ) :

· Prototype
o declares an interface for cloning itself.
· ConcretePrototype
o implements an operation for cloning itself.
· Client
o creates a new object by asking a prototype to clone itself. 

원리 ( Collaborations ) :

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

Prototype has many of the same consequences that Abstract Factory and Builder have: It hides the concrete product classes from the client, thereby reducing the number of names clients know about. Moreover, these patterns let a client work with application-specific classes without modification.

Additional benefits of the Prototype pattern are listed below.

1. Adding and removing products at run-time. Prototypes let you incorporate a new concrete product class into a system simply by registering a prototypical instance with the client. That's a bit more flexible than other creational patterns, because a client can install and remove prototypes at run-time.

2. Specifying new objects by varying values. Highly dynamic systems let you define new behavior through object composition—by specifying values for an object's variables, for example—and not by defining new classes. You effectively define new kinds of objects by instantiating existing classes and registering the instances as prototypes of client objects. A client can exhibit new behavior by delegating responsibility to the prototype. This kind of design lets users define new "classes" without programming. In fact, cloning a prototype is similar to instantiating a class. The Prototype pattern can greatly reduce the number of classes a system needs. In our music editor, one GraphicTool class can create a limitless variety of music objects.

3. Specifying new objects by varying structure. Many applications build objects from parts and subparts. Editors for circuit design, for example, build circuits out of subcircuits.1 For convenience, such applications often let you instantiate complex, user-defined structures, say, to use a specific subcircuit again and again. The Prototype pattern supports this as well. We simply add this subcircuit as a prototype to the palette of available circuit elements. As long as the composite circuit object implements Clone as a deep copy, circuits with different structures can be prototypes.  

4. Reduced subclassing. Factory Method often produces a hierarchy of Creator classes that parallels the product class hierarchy. The Prototype pattern lets you clone a prototype instead of asking a factory method to make a new object. Hence you don't need a Creator class hierarchy at all. This benefit applies primarily to languages like C++ that don't treat classes as first-class objects. Languages that do, like Smalltalk and Objective C, derive less benefit, since you can always use a class object as a creator. Class objects already act like prototypes in these languages.

5. Configuring an application with classes dynamically. Some run-time environments let you load classes into an application dynamically. The Prototype pattern is the key to exploiting such facilities in a language like C++. An application that wants to create instances of a dynamically loaded class won't be able to reference its constructor statically. Instead, the run-time environment creates an instance of each class automatically when it's loaded, and it registers the instance with a prototype manager (see the
Implementation section). Then the application can ask the prototype manager for instances of newly loaded classes, classes that weren't linked with the program originally. The ET++ application framework [WGM88] has a run-time system that uses this scheme.
The main liability of the Prototype pattern is that each subclass of Prototype must implement the Clone operation, which may be difficult. For example, adding Clone is difficult when the classes under consideration already exist. Implementing Clone can be difficult when their internals include objects that don't support copying or have circular references.

관련 패턴들 : 

 Prototype and Abstract Factory are competing patterns in some ways, as we discuss at the end of this chapter. They can also be used together, however. An Abstract Factory might store a set of prototypes from which to clone and return product objects.
Designs that make heavy use of the Composite and Decorator patterns often can benefit from Prototype as well.

추가 정보 :     

• Sometimes creational patterns are competitors: there are cases when either Prototype or Abstract Factory could be used properly. At other times they are complementory: Abstract Factory might store a set of Prototypes from which to clone and return product objects. Abstract Factory, Builder, and Prototype can use Singleton in their implementations.
• Abstract Factory classes are often implemented with Factory Methods, but they can be implemented using Prototype.
• Factory Method: creation through inheritance. Protoype: creation through delegation.
• Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Protoype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.
• Prototype doesn't require subclassing, but it does require an "initialize" operation. Factory Method requires subclassing, but doesn't require Initialize.
• Designs that make heavy use of the Composite and Decorator patterns often can benefit from Prototype as well.
• Prototype co-opts one instance of a class for use as a breeder of all future instances.
• Prototypes are useful when object initialization is expensive, and you anticipate few variations on the initialization parameters. In this context, Prototype can avoid expensive "creation from scratch", and support cheap cloning of a pre-initialized prototype.
• Prototype is unique among the other creational patterns in that it doesn't require a class – only an object. Object-oriented languages like Self and Omega that do away with classes completely rely on prototypes for creating new objects.

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

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

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.

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

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

Factory Method Pattern Structure

패턴의 목적 ( Intent ) : 

 Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

팩토리 메소드 패턴은 하나의 객체를 생성하는 인터페이스를 정의하는데 이때 어떤 객체를 생성할 것인지에 대한 결정권은 서브클래스에게 위임한다. 

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

프 레임워크는 일반적으로 추상클래스로 객체 사이의 관계를 정의하는데, 종종 객체를 생성해야 할 때도 있다. 아래 다이어그램은 다양한 종류의 문서를 사용자에게 보여줄 수 있는 프레임워크의 클래스 다이어그램이다. 아래 다이어그램에서 관계를 맺고 있는 추상클래스들은 Document와 Application이다. 사용자가 그림그리기 애플리케이션을 만들려면 두 추상클래스를 상속받아 DrawingApplication과 DrawingDocument 클래스를 정의해야하고, Application클래스는 필요에따라 Document 클래스를 생성 혹은 열기가 가능해야 한다. 

자, 그런데 문제는 특정 문서는 특정 애플리케이션에 의존적이라는 점이다. 예를 들어, docx는 워드에서 생성하는 문서이지 한글에서 생성하는 문서가 아닌 것과 같은 현상이라고 보면 된다. 따라서 Application의 CreateDocument()를 추상메소드로 정의하고 이를 서브클래스에서 구현하도록 하여 각각의 Application마다 각각의 Document를 생성하도록 한 것이다. 이때 CreateDocument()를 팩토리 메소드라고 부른다. 

유용성 ( Applicability ) :

 Use the Factory Method pattern when

· a class can't anticipate the class of objects it must create.
· a class wants its subclasses to specify the objects it creates.
· classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

등장 인물 ( Participants ) :

· Product (Document)
o defines the interface of objects the factory method creates.
· ConcreteProduct (MyDocument)
o implements the Product interface.
· Creator (Application)
o declares the factory method, which returns an object of type Product. Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object.
o may call the factory method to create a Product object.
· ConcreteCreator (MyApplication)
o overrides the factory method to return an instance of a ConcreteProduct.

원리 ( Collaborations ) :

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

 Factory methods eliminate the need to bind application-specific classes into your code. The code only deals with the Product interface; therefore it can work with any user-defined ConcreteProduct classes. A potential disadvantage of factory methods is that clients might have to subclass the Creator class just to create a particular ConcreteProduct object. Subclassing is fine when the client has to subclass the Creator class anyway, but otherwise the client now must deal with another point of evolution. 

Here are two additional consequences of the Factory Method pattern:

1. Provides hooks for subclasses. Creating objects inside a class with a factory method is always more flexible than creating an object directly. Factory Method gives subclasses a hook for providing an extended version of an object.
In the Document example, the Document class could define a factory method called CreateFileDialog that creates a default file dialog object for opening an existing document. A Document subclass can define an application-specific file dialog by overriding this factory method. In this  case the factory method is not abstract but provides a reasonable default implementation.

2. Connects parallel class hierarchies. In the examples we've considered so far, the factory method is only called by Creators. But this doesn't have to be the case; clients can find factory methods useful, especially in the case of parallel class hierarchies.
Parallel class hierarchies result when a class delegates some of its responsibilities to a separate class. Consider graphical figures that can be manipulated interactively; that is, they can be stretched, moved, or rotated using the mouse. Implementing such interactions isn't always easy.
It often requires storing and updating information that records the state of the manipulation at a given time. This state is needed only during manipulation; therefore it needn't be kept in the figure object. Moreover, different figures behave differently when the user manipulates them. For example, stretching a line figure might have the effect of moving an endpoint, whereas stretching a text figure may change its line spacing. With these constraints, it's better to use a separate Manipulator object that implements the interaction and keeps track of any manipulation-specific state that's needed. Different figures will use different Manipulator subclasses to handle particular interactions. The resulting Manipulator class hierarchy parallels (at least partially) the Figure class hierarchy:

The Figure class provides a CreateManipulator factory method that lets clients create a Figure's corresponding Manipulator. Figure subclasses override this method to return an instance of the Manipulator subclass that's right for them. Alternatively, the Figure class may implement CreateManipulator to return a default Manipulator instance, and Figure subclasses may simply inherit that default. The Figure classes that do so need no corresponding Manipulator subclass—hence the hierarchies are only partially parallel.
Notice how the factory method defines the connection between the two class hierarchies. It localizes knowledge of which classes belong together.

관련 패턴들 : 

 Abstract Factory is often implemented with factory methods. The Motivation example in the Abstract Factory pattern illustrates Factory Method as well.
Factory methods are usually called within Template Methods. In the document example above, NewDocument is a template method.
Prototypes don't require subclassing Creator. However, they often require an Initialize operation on the Product class. Creator uses Initialize to initialize the object. Factory Method doesn't require such an operation.

추가 정보 :     

• Abstract Factory classes are often implemented with Factory Methods, but they can be implemented using Prototype.
• Factory Methods are usually called within Template Methods.
• Factory Method: creation through inheritance. Prototype: creation through delegation.
• 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.
• Prototype doesn't require subclassing, but it does require an Initialize operation. Factory Method requires subclassing, but doesn't require Initialize.
• The advantage of a Factory Method is that it can return the same instance multiple times, or can return a subclass rather than an object of that exact type.
• Some Factory Method advocates recommend that as a matter of language design (or failing that, as a matter of style) absolutely all constructors should be private or protected. It's no one else's business whether a class manufactures a new object or recycles an old one.
• The new operator considered harmful. There is a difference between requesting an object and creating one. The new operator always creates an object, and fails to encapsulate object creation. A Factory Method enforces that encapsulation, and allows an object to be requested without inextricable coupling to the act of creation.