디자인 패턴 요약

 

[디자인 패턴 요약 및 정리]

 

 

패턴명칭	설명	특징
Abstract Factory	클래스를 직접 생성하지 않고, 클래스를 생성하는 클래스를 별도로 두어 추가적인 클래스 생성에 대한 부담을 줄여주는 패턴(COM 의 Factory 와 동일)	- 클라이언트 프로그램이 직접 클래스를 생성하지 않아도 되기 때문에 사용하는 클래스로부터 종속되지 않게 된다.
Builder	하나의 소스 객체에서 복잡한 여러 개의 객체를 만들 수 있도록 하는 패턴	- 복잡한 객체 생성 부분은 클라이언트에게 보이지 않는다   - Builder 는 가상 클래스로 정의되고 실제 객체가 하는 일은 Builder 를 상속받은 Concrete 클래스가 맡아 처리한다.
Factory Method	클래스를 직접 생성하지 않고, 대행 함수를 통해 간접적으로 객체를 생성하는 방식   Factory Method 는 상위클래스에서 가상함수로 정의되고 상속받은 하위 클래스에서 실제 객체를 생성하는 역할을 담당	-  생성할 객체의 자료형이 하위 클래스에 의해 결정됨   - 하위 클래스들에게 개별 객체의 생성 책임을 분산시켜 객체의 종류별로 객체 생성과 관련된 부분을 국지화 할 수 있다.
Prototype	생성할 모든 객체를 미리 만들어 두고, 추후 객체 생성시에는 만들어둔 객체를 복사(Clone)하여 새로운 객체를 생성하는 방법 Prototype Manager – 복제할 원본객체들을 모아 관리하는 객체	- 객체를 생성하는 시점에 객체의 자료형을 몰라도 된다(이미 생성한 객체의 복사를 통해 객체 생성, 객체의 자료형을 알기 위해 복잡한 switch 문을 필요로 하지 않는다) - 클라이언트 입장에서는 모든 서로 다를 객체를 알 필요 없이 Prototype 인터페이스로만 접근 가능 - 생성할 객체가 런타임에 결정될 경우 유용하다.
Singleton	최대 N 개로 객체생성을 제한하고자 할 경우 사용 생성자 및 복제 연산자를 private 이나, protected로 선언하여 일반적인 방법으로는 객체가 생성될 수 없게 해야 함.	- Singleton 으로 생성할 개체는 대부분 별도 생성을 위한 global 함수나 static 멤버 함수를 통해 생성한다.
Adapter	기존 클래스 상속구조와 틀린 인터페이스를 가진 클래스가 신규 추가될 경우 이 클래스를 기존 상속에 묶기 위해 Adapter 클래스로 추가된 클래스를 Wrapping 하는 방법. Adapter 패턴에는 객체를 참조하는 방식인 Object Adapter 와 다중 상속을 통한 방법인 Class Adapter 가 있음.	- 기존 클래스를 재사용하려고 하나 그 인터페이스가 원하는 것과 동일하지 않을 때 사용   - 클라이언트는 새로 추가된 클래스가 기존과 다른 인터페이스를 가지고 있더라도 Adapter 로 인해, 기존 클래스와 동일한 인터페이스를 통해 제어 가능
Bridge	외부에 공개되는 인터페이스 및 그에 따른 논리적 관점의 클래스 상속구조와 이들을 구현하기 위한 클래스의 상속구조를 독립적으로 정의하고, 논리적 관점의 클래스에서 구현클래스를 참조하는 형태로 설계된 클래스   인터페이스 클래스와 그것을 구현해 주는 클래스들의 상속관계를 독립적으로 정의하고 이들간을 마치 다리처럼 연결해주는 형태의 클래스 구조를 가리킨다.	- 사용용도에 따른 논리적 관점의 클래스 상속구조와 구현 플랫폼 별 클래스 상속구조를 별개로 정의 - 인터페이스와 구현을 분리시켜 준다. - 인터페이스와 실 구현이 서로 복잡하게 연결되는 것을 간소화 할 수 있다. - 인터페이스와 구현방식이 각각 서로 다른 형태의 하위 클래스 구조를 가지면서 확장할 수 있다. - 인터페이스의 구현이 변경되더라도 클라이언트소스는 재 컴파일이 필요 없다.
Composite	하나이상의 객체로 이루어진 복합객체를 기존 객체와 동일한 인터페이스로 접근할 수 있도록 해 주는 패턴(Adapter 와 많이 닮았음)	- 복합객체는 부품이 되는 단일객체와 동일한 인터페이스를 가짐   - 클라이언트는 단일 객체와 복합객체를 단일한 인터페이스로접근
Decorator	이미 생성된 객체에 동적으로 신규 기능을 추가하고자 할 경우, 신규 기능을 지원하는 클래스를 linked list 방식으로 계속 해서 추가해 나가는 방식(linked list 에 들어갈 기능들은 모두 동일한 인터페이스여야 함)	- 특정객체에 동적으로 새로운 기능을 추가/삭제 하고자 할 경우 사용
Facade	클라이언트가 A>B>C>D 와 같은 순서로 여러 클래스를 호출하여 결과를 얻어야 할 경우, (A>B>C>D) 를 하나로 묶어 처리하는 대표(Facade) 클래스를 정의하여 처리하도록 제공하는 패턴	- 복잡한 서브시스템에 대해 간단한 인터페이스를 제공하고자 할 경우 유용 - 클라이언트와 구현클래스간 의존관계를 감소하는 방안으로 사용
Flyweight	여러 객체에서 공통으로 사용되는 정보를 그렇지 않은 정보와 분리하고 공유 가능한 정보를 객체형태로 정의해서 정보공유를 수행하는 형태의 설계	- 객체공유를 통해 자원 사용량을 줄여주기 위한 설계   - Factory Method 패턴이나, Singleton 패턴을 사용하여 객체를 생성, 공유한다.
Proxy	기본적으로 어떤 역할을 수행하고 있는 클래스가 존재할 때 그 클래스가 제공하는 기능이나 역할을 그대로 활용하면서 부가적인 기능이나 역할을 수행해 주기 위해 새로운 클래스를 정의하고 클라이언트의 모든 요청을 새로 정의한 클래스 객체를 거쳐 원래의 클래스객체에게 전달하는 방식의 클래스 구조	- 새로 정의한 클래스(Proxy) 는 원래 존재하는 클래스와 동일한 인터페이스를 제공해야 한다. (클라이언트 수정 최소화)   - 새로 정의한 클래스를 통해 클라이언트 코드 수정 없이 추가적으로 더 많은 일을 수행하는 대행 클래스를 정의 할 수 있다.
Chain of Responsibility	객체들간의 관계에 의해 체인을 구성해두고 특정 객체에게 요청이 전달될 경우, 해당 객체가 요청을 처리하지 못하면 체인상에 있는 다른 객체에게 요청을 대신 처리하게 하는 방식의 설계	- 하나 이상의 객체가 요청을 처리할 수 있고 미리 어떤 객체가 요청을 처리할 지는 알지 못하며, 실제 요청을 처리하는 객체는 자동으로 결정되기를 원할 경우 사용   - 단점: 요청이 제대로 처리되는지, 처리 시간이 얼마나 걸릴지 알 수 없음.
Command	여러가지 요청(Command) 들에 대해 이를 처리해야 하는 클라이언트의 부담을 줄이고 추가/삭제를 용이하게 하기 위해 요청과 요청을 처리할 객체를 중계하기 위한 클래스 상속구조   Command 클래스는 요청을 처리할 객체를 내부적으로 미리 저장, 관리하고 요청이 들어오면 요청을 처리할 객체의 멤버 함수를 불러주는 역할	- 미리 map와 같이 명령문자열과, 실제 이를 처리할 클래스(ICommand 인터페이스 상속받음)를 생성, 관리해야 한다.    - 클라이언트는 명령이 들어올 경우 명령을 자동 연결 처리할 클래스에게 바로 위임시킬 수 있다.
Interpreter	- 간단한 문법에 기반한 검증 및 작업 처리 문제	- 복잡한 문법 보다 간단한 문법이 주어졌을 때 적용하는 거싱 좋다.
Iterator	STL 의 Iterator 를 생각하면 됨. 데이터 아이템을 가진 데이터 클래스와 이를 navigation 할 수 있는 Iterator 클래스를 정의해서 사용	- 복잡한 데이터 클래스의 내부를 알 필요 없이 각 항목별로 접근할 때 유용   - 서로 다른 Aggregate 클래스 객체에 대해 각 항목을 접근하기 위한 인터페이스를 동일하게 정의하고자 할 때
Mediator	M 개의 클래스가 각자 별도로 연결될 경우 각 클래스간 연결이 M:N 이 되어 복잡해 질 수 있음. 이를 해결 하기 위해 M 개의 클래스가 직접 연결하지 않고 Mediator 클래스를 통해 서로를 연결하는 방법	- 객체들간의 복잡한 상호작용이 존재해서 서로간의 의존관계가 불명확하고 이해하기 힘들 때   - 하나의 객체가 다른 많은 객체들을 참조하거나 상호작용하고 있어 재사용이 힘들 때
Memento	객체의 상태 정보를 별도의 클래스로 정의하고, 리스트 자료구조에 그 클래스의 객체를 필요한 시점마다 저장해두었다가 특정 시점에서 객체의 상태복원을 쉽게 할 수 있도록 만든 클래스 구조	- 어떤 객체의 특정시점에 대한 상태 정보가 나중에 복원되기 위해 저장되어야 할 때 사용
Observer	하나의 소스데이터를 여러 곳에서 참조할 경우 소스가 변경됨을 손쉽게 참조하는 클래스로 전달해주는 클래스 구조 COM 의 EVENT SINK 방식과 유사	- Subject 클래스는 자신의 객체에 의해 영향 받을 Observer 객체들을 등록, 삭제할 수 있는 Attach, Detach 멤버 함수를 제공
State	어떤 객체의 내부 상태가 계속 변경될 가능성이 있을 때 새로운 상태의 추가도 쉽도록 만들어 주고, 추가된 상태를 포함해서 객체의 상태 변화 시 기존 소스코드 변경 없이 행위 수행 변경이 가능하도록 객체 상태 정보를 클래스 상속구조로 정의해서 사용하는 방식	- IState 라는 인터페이스를 정의하고, 상태1, 상태2, 상태3 등을 모두 IState 를 상속받도록 한 다음, 내부상태가 변경될 때마다 상태1 > 상태2 식으로 객체를 변경하여 사용하는 방식   - 클라이언트는 IState* 만 사용하기 때문에 객체의 상태 변경에 대한 코드 변경 부담이 적음
Strategy	여러가지 전략중 하나를 동적으로 적용할 필요가 있을 경우 IStrategy 인터페이스를 정의하고, 이를 상속받는 다양한 전략클래스를 정의한 다음, 클라이언트의 필요에 맞는 전략을 사용하는 방법	- 서로 행위만 다를 뿐 밀접한 연관을 가진 여러 클래스들에 대해 필요한 시점에 어느 한 행위를 수행하는 클래스를 골라 사용하고자 할 경우 유용
Template Method	구체적인 구현은 다르나 큰 틀에서 알고리즘의 기본 골격이 동일한 경우, 동일한 기본 골격을 상위클래스에서 하나의 모듈로 작성, 관리할 수 있게 되는 데 이를 Template Method 라 하고 이를 포함하는 클래스 구조를 Template Method 패턴이라고 함.	- A 클래스와 B 클래스 상세 구현은 다르나 하는 일이 거의 같은 경우 공통적인 부분을 하나의 상위 클래스에서 구현하도록 하고 이를 상속받도록 함.   - 구현부분에 있어 일부 달라지는 부분은 최상위클래스는 인터페이스만 정의하고 하위 클래스가 이를 실제 구현함
Visitor	새로운 작업의 추가, 변경이 쉽도록 작업대상과 작업항목을 각각 별도의 클래스 상속구조로 분리해서 정의하고, Double-Dispatch 방식에 따라 작업수행이 일어나게 클래스를 설계한 것	- 다양한 인터페이스를 가진 객체 여러 개에 대해 그들의 자료형에 따라 각각의 작업을 수행하고 싶을 때   - 작업대상이 되는 클래스 구조는 확장될 가능성이 없는 대신 수행할 작업 항목은 계속해서 추가, 확장될 소지가 많을 때 유용

  

* 참고할만한 자료

: https://gmlwjd9405.github.io/tags#design-pattern

GoF Design Patterns Card.pdf

0.08MB

designpatternsinjava_src-inter999.zip

1.74MB

GoF 활용 예제.zip

0.72MB

Design Patterns in java.doc

2.6MB

GoF_OOP.doc

0.84MB