GOF - Software Design Pattern

왜 디자인 패턴을 사용하나?

• 재사용 가능하고, 유연한 구조를 가지는 소프트웨어 개발
• 커뮤니케이션 : 구체적인 설명 없이 구조화된 패턴에 대한 사전 지식으로 커뮤니케이션에 드는 비용, 비용 절약.
• 설계 과정의 속도를 높일 수 있음. 이미 검증되고 테스트된 구조이기 때문.
• 구현이 아닌 인터페이스에 맞춰서 프로그래밍
• 바뀌는 부분은 따로 뽑아서 캡슐화.
• 상속 보다는 구성을 활용. → 구성을 활용하면 유연성을 크게 향상 시킴.

Principles of Design Patterns

• Interface Separated from implementation
• Substitution with various implementation
• Open Closed Principle (OCP)

Classification of Design Patterns

Creation Patterns

객체 생성에 관련된 패턴. 객체의 생성과 조합을 캡슐화해 특정 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공한다.

Structure Patterns

클래스나 객체를 조합해 더 큰 구조를 만드는 패턴

예를 들어 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스를 제공하거나 객체들을 서로 묶어 새로운 기능을 제공하는 패턴이다.

Behavioral Patterns

객체나 클래스 사이의 알고리즘이나 책임 분배에 관련된 패턴 한 객체가 혼자 수행할 수 없는 작업을 여러 개의 객체로 어떻게 분배하는지, 또 그렇게 하면서도 객체 사이의 결합도를 최소화하는 것에 중점을 둔다.

 

---

생성 패턴

Factory Method : 객체를 생성하기 위해 인터페이스를 정의하지만, 어떤 클래스의 인스턴스를 생성할지에 대해서는 하위

클래스에서 결정 -> 클래스의 상속 이용, 인터페이스의 다형성

Abstract Factory : 구체적 클래스를 정의하지 않고도 서로 관련성이 있거나 독립적인 여러 객체의 군을 생성하기 위한 인터

페이스 제공

Builder : 데이터의 순서에 상관없이 객체 생성 가능. setter 메서드가 없으므로 변경 불가능한 객체 생성 가능. 한번에 객체

를 생성하므로 객체 일관성이 깨지지 않음.

Prototype : 객체를 생성하는데 비용이 들고, 이미 유사한 객체가 존재하는 경우에 사용. Client에 Map 형태로 생성될 객체

를 등록해놓고, 타입에 따라 객체를 clone 하는 형태로 객체 생성. ex) DB로부터 읽어온 객체 등록 후 복사.

Singleton : 클래스에서 만들 수 있는 인스턴스가 오직 하나일 경우. 어디에서 접근 하든지 하나로만 통일하여 제공.

 

구조 패턴

Adapter : 클래스의 인터페이스를 클라이언트가 기대하는 형태의 인터페이스로 변환. 기존의 클래스를 사용해야 하나 인터페이스가 수정되어야 하는 경우에 사용. adapter 클래스의 멤버로 타겟 클래스를 가짐. (has a) Adaptee 클래스의 하위 클래스기 때문에 곧바로 Adaptee의 멤버 함수들을 override 할 수 있다.

Bridge : 구현부에서 추상층을 분리하여 각자 독립적으로 변형이 가능하고 확장이 가능하도록 합니다. 즉 기능과 구현에 대

해서 두 개를 별도의 클래스로 구현을 합니다. 런타임 시 구현 방법을 선택하거나 구현 내용을 변경하고 싶은 경우 사용.

Composite : 부분과 전체의 계층을 표현하기 위해 복합 객체를 트리 구조로 만드는 패턴. 복합 객체와 단일 객체의 처리 방법이 다르지 않을 경우, 전체-부분 관계로 정의. Directory-File 존재. SRP를 깨는 대신 투명성을 확보하는 패턴. 투명성(transparency)란 Component 인터페이스에 자식들을 관리하는 기능과 leaf으로써의 기능을 전부 넣어서 클라이언트가 복합 객체와 잎을 똑같은 방식으로 처리할 수 있도록 만들 수 있다.

Decorator : 객체에 동적으로 새로운 서비스를 추가 할 수 있게 한다. 기능의 추가를 위해서 하위 클래스를 생성하는것보다 융통성 있는 방법을 제공. (상속보다 위임을 통하여 제공)

Flyweight : 어떤 클래스의 인스턴스 한개만 가지고 여러 개의 "가상 인스턴스"를 제공하고 싶을때 사용하는 패턴. 즉 인스

턴스를 가능한 대로 공유시켜 쓸데없는 new 연산자를 통한 메모리 낭비를 줄이는 방식. 대규모의 미세한 객체들을 효과적

으로 사용하기 위해서 공유 개념 도입.

Facade : 복잡한 서브시스템에 대한 단순한 인터페이스 제공이 필요할때. 클라이언트와 구현 클래스 간에 너무 많은 종속

성이 존재하여 클라이언트와 다른 서브 시스템 간의 결합도를 낮추고 싶을 때.

Proxy : 프록시에게 일을 대신 시킴. 어떤 객체 사용할때, 직접 참조하는것이 아닌 해당 객체를 대항하는 객체를 통해 대상

객체에 접근하는 방식을 사용하면 해당 객체가 메모리에 존재하지 않아도 기본적인 정보를 참조하거나 설정할 수 있고, 실

제 객체의 기능이 필요한 시점까지 객체의 생성을 미룰 수 있음. 사이즈가 큰 객체가 로딩되기전에 프록시를 통해 참조 가

능. 객체 생서이 한단계 거치게 되므로 빈번한 객체 생성시에 성능 저하.

 

 

행위 패턴

Template Method : 알고리즘의 변하지 않는 부분을 한 번 정의하고 다양해질 수 있는 부분을 하위 클래스에서 정의할 수 있

도록 구현하고자 할 때. 훅을 사용하여 하위 클래스 확장을 제어 가능. 코드 재사용을 위한 기본 기술.

Strategy : 다양한 알고리즘이 존재하면 이들 각각을 하나의 클래스로 캡슐화하여 알고리즘의 대체가 가능하도록 함. 행위

들이 조금씩 다를 뿐 개념적으로 관련된 많은 클래스들이 존재하는 경우.

State : 객체 내부의 상태에 따라 행위를 변경하도록 함.상태에 따른 행위를 국지화하여 서로 다른 상태에 대한 행위를 별도

의 객체로 관리함. 상태 전이 규칙을 명확하게 만듬. 상태 객체는 공유 될 수 있음.

Command : 요청 자체를 객체화 하는것. 서로 다른 요청을 객체화하여 클라이언트에게 파라미터로 넘겨 줄 수 있게 한다.

Chain of Responsibility : 메시지를 보내는 객체와 이를 받아 처리하는 객체들 간의 결합도를 없애기 위한 패턴. 메시지를

수신하여 처리를 담당하는 객체들을 하나의 연결 고리로 만들고 실제로 요청을 처리하는 객체를 만날 때까지 계속 요청을

전달. 메시지를 받을 객체를 명시하지 않은 채 여러 객체 중 하나에게 처리를 요청하고 싶을때 사용.

Memento : 캡슐화를 위배하지 않으면서 객체의 내부 상태를 파악하고 표현함으로써 객체의 상태를 저장해 둔 상태로 다시

복귀할 수 있게 함. 각 시점에서의 객체 상태를 저장한 후 나중에 이 상태로 복구해야 할 때 활용.

Observer : 일대다의 관련성을 갖는 객체들의 경우 한 객체의 상태가 변하면 다른 모든 객체에 그 사항을 알리고 필요한 수

정이 자동으로 이루어지도록 할 때. 프로그래머는 얼마나 많은 객체들이 변경되어야 하는지 몰라도 됨.

Iterator : 복합 객체 요소들의 내부 표현 방식을 공개하지 않고도 순차적으로 접근할 수 있는 방법을 제공. (구현과 순회 분

리)

Visitor : 데이터 구조와 처리를 분리. 데이터 구조 안을 돌아다니는 주체인 방문자를 나타내는 클래스를 준비해서 처리를

맡긴다. 새로운 처리를 추가하고 싶을 땐 새로운 방문자를 만들고 데이터 구조는 방문자를 받아들이면 됨. OCP적용. 새로

운 concreteelement 클래스 추가하기는 어려움.

Mediator :클래스 간의 복잡한 관계를 캡슐화하여 하나의 클래스에서 관리하도록 처리하는 패턴. M:N 관계를 M:1 관계로

만들어 복잡도를 내리므로 유지 보수 및 확장성에 유리.

Interpretor : 간단한 언어의 문법을 정의하고 싶을 때

---

Facade 패턴과 Mediator 패턴

• Mediator의 역할은 Colleague 역할의 중재자로서 주고받기를 수행함 -> 양방향
• Facade 역할은 일방적으로 다른 역할을 이용해서 높은 레벨의 인터페이스(API)를 만듦 -> 단방향
• 퍼사드가 자신의 정책을 가시적이고 강제적으로 적용하는 반면, 미디에이터는 자신의 정책을 은밀하고 강제적이지 않은 방식으로 적용한다.
• 퍼사드 패턴은 클래스 라이브러리와 같은 어떤 소프트웨어의 다른 커다란 코드 부분에 대한 Unified Interface를 제공하며, 퍼사드는 그러한 인터페이스를 제공하는 객체다.
• 미디에이터 패턴은 객체들의 집합이 상호작용하는 방법을 함축해놓은 객체를 정의한다. 객체 간 통신은 미디에이터 객체 안에 함축된다. 객체들은 서로 직접 통신하지 않으며, 미디에이터를 통해 통신한다. 이를 통해 객체 간 의존성을 줄여 결합도를 감소시킬 수 있다.

Observer 패턴과 Mediator 패턴

• 옵저버 패턴은 1개의 publisher에 대해 N개의 subscriber가 존재. 옵저버는 pulling이나 push 방식을 통해 관리.
• 중재자 패턴은 M개의 publisher와 N개의 subscriber 사이에서 1개의 중재자를 통해 통신하는 방식.

Prototype 패턴과 Flyweight 패턴

• Prototype은 복제를 하는 것이고 Flyweight는 있는것 그대로 쓴다.

 

Strategy Pattern

알고리즘을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. Strategy를 활용하면 알고리즘을 사용하는 클라이언트와 독립적으로 알고리즘을 변경할 수 있다.

특징

• 관련 알고리즘의 군을 형성함
• 서브클래싱을 사용하지 않른 방법.
• 사용자는 서로 다른 전략을 알고 있어야 함
• Strategy와 Context 클래스 사이에 과다한 메시지가 전송됨
• 객체 수가 증가

Observer Pattern

한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one to many) 의존성을 정의.

일반적으로, Subject 인터페이스와 Observer 인터페이스가 들어있는 클래스 디자인을 바탕으로 구현.

Subject와 Observer가 Loose coupling 되어 있는 개체 디자인을 제공

 

데이터 가져오는 방식

pulling : 루프를 돌면서 계속 호출

pushing : 등록하면, 변경되었을때 통지

observe : 항상 필요X, 선택적으로 필요, notification만 전달받고, data는 전달받지 않음.

 

특징

• Subject가 Observer에 대하여 아는것은 Observer가 특정 인터페이스를 구현한다는 것뿐.
• Observer는 언제든지 새로 추가 가능.
• 새로운 형식의 Observer를 추가하려고 할 때도 Subject를 전혀 변경 할 필요가 없음.
• Subject, Observer 는 서로 독립적으로 재사용 가능. 서로 영향을 미치지 않음.

서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다.

 

Decorator Pattern

객체에 추가적인 요건을 동적으로 첨가한다. 데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장 할 수 있는 방법을 제공.

예) 카페에서 음료 제조시, 첨가물을 데코로 표현.

Open Closed Principle

"클래스는 확장에 대해서는 열려 있어야 하지만 코드 변경에 대해서는 닫혀 있어야 한다."

 

Class Diagram

특징

• 기존 코드는 건드리지 않은 채로 확장을 통해서 새로운 행동을 간단하게 추가할 수 있음
• 이 목표를 달성했을 때 새로운 기능을 추가하는데 있어서 매우 유연해서 새로 급변하는 주변 환경에 잘 적응할 수 있으면서도 강하고 튼튼한 디자인을 만들 수 있음.
• 데코레이터의 슈퍼 클래스는 자신이 장식하고 있는 객체의 슈퍼클래스와 같음.
• 한 객체를 여러 개의 데코레이터로 감쌀 수 있음.
• 데코레이터는 자신이 감싸고 있는 객체와 같은 슈퍼클래스를 가지고 있기 때문에 원래 객체가 들어갈 자리에 데코레이터 객체를 집어넣어도 상관없음.
• 데코레이터는 자신이 장식하고 있는 객체에게 어떤 행동을 위임(Delegate)하는 것 외에 원하는 추가적인 작업을 수행할 수 있음. – 키 포인트
• 객체는 언제든지 감쌀 수 있기 때문에 실행 중에 필요한 데코레이터를 마음대로 적용할 수 있음.

데코레이터를 사용하는 목적은 컴파잉리할 때 모든 서비스의 객체를 다 결정할 수 없는 상황에서 적절하게 대응하기 위해서임.

 

Factory method pattern

모든 팩토리 패턴에서는 객체 생성을 캡슐화.

팩토리 메소드 패턴에서는 서브클래스에서 어떤 클래스를 만들지를 결정함으로써 객체 생성을 캡슐화.

예제 ) 피자 가게에서 피자 생성

Dependency Inversion Principle

추상화된 것(Abstract or Interface)에 의존하도록 만들어라. Concrete Class에 의존하지 않도록 한다.

 

Class Diagram

 

특징

• 어떤 변수에도 구상 클래스에 대한 레퍼런스를 저장하지 말 것.
  클라이언트에서 New 연산자를 사용하면 구상 클래스에 대한 레퍼런스를 사용하게 되는 것.
  이 패턴을 사용하여 구상 클래스에 대한 레퍼런스를 변수에 저장하는 일을 미리 방지.
• "New" 연산자를 캡슐화

 

Abstract Factory Method Pattern

추상 팩토리 패턴에서는 인터페이스를 이용하여 서로 연관된, 또는 의존하는 객체를 구상 클래스를 지정하지 않고도 생성 가능.

 

Class Diagram

 

Factory Method vs Abstract Factory Method

• 공통 : 둘다 객체 생성 패턴. 객체 생성을 캡슐화해서 Client와의 결합을 느슨하게 하고, 특정 구현에 덜 의존하도록 만듬.
• 차이점 : Factory Method는 상속을 통해서 객체를 생성. Abstract Factory Method는 객체 구성(Composition)을 통해 생성.
• 팩토리 메서드 패턴을 통해 객체 생성시에는 클래스를 확장하고 팩토리 메서드를 오버라이딩 해야 함.
• 팩토리 메서드 패턴을 사용한다는것은 서브 클래스를 통해서 객체를 만들기 위한 것. 클라이언트에서는 자신이 사용할 추상 형식만 알면 되고, 구상 형식은 서브클래스에서 처리해 줌. 즉, 클라이언트와 구상 형식을 분리해주는 역할

 

Singleton Pattern

해당 클래스의 인스턴스가 하나만 만들어지고, 어디서든지 그 인스턴스에 접근할 수 있도록 하기 위한 패턴.

Double Checked Locking 에서 volatile 키워드 관련 알고 있을것.

 

특징

• 한 앱에 들어 있는 어떤 객체에서도 똑같은 자원을 활용할 수 있도록 함.
  예) 쓰레드 풀, 연결 풀 등 자원 풀을 관리하는게 유용함.
• 단순 싱글턴 패턴 적용시 멀티 쓰레딩에 따른 문제가 발생할 수 있음. synchronized, volatile 등 사용 할 것

 

Command Pattern

어떤 작업을 요청한 쪽과 그 작업을 처리하는 쪽을 분리 시킬 수 있음. 커맨드 객체는 특정 객체에 대한 요청을 캡슐화 시켜줌.

 

Class Diagram

특징

• 오퍼레이션을 호출하는 객체와 오퍼레이션을 수행 방법을 구현하는 객체를 분리.
• 요구사항을 캡슐화.
• Command 자체도 클래스로서 다른 객체와 같은 방식으로 조작되고 확장될 수 있음.
• 명령어를 조합해서 다른 명령어를 만들 수 있음. (Composite 패턴 활용)
• 새로운 명령어를 쉽게 추가 할 수 있음.

 

Adapter Pattern

한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환합니다. 어댑터를 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 쓸 수 있습니다.

 

클라이언트 : 타겟 인터페이스에 맞게 구현되어 있음.

어댑터 : 타겟 인터페이스를 구현하며, 여기에는 어댑티 클래스가 들어 있음.

 

클라이언트에서 어댑터 사용하는 방법

• 클라이언트에서 타겟 인터페이스를 사용하여 메소드를 호출함으로써 어댑터에 요청
• 어댑터에서는 어댑티 인터페이스를 사용하여 그 요청을 어댑티에 대한 (하나 이상의) 메소드 호출로 변환
• 클라이언트에서는 호출 결과를 받긴 하지만 중간에 어댑터가 껴 있는지는 전혀 알지 못함.

Class Diagram

• Client는 Target 인터페이스를 구현한 Adaptee가 필요하다.
• Adaptee는 Target인터페이스를 구현하지 않고 있다.
  • Adaptee는 이미 개발이 완료되어 사용중이다.
  • Adaptee를 변경하는 것이 적절하지 않은 상황이다.

특징

어댑티를 새로 바뀐 인터페이스로 감쌀 때는 composition을 사용합니다. 이런 접근법을 쓰면 어댑티의 어떤 서브 클래스에 대해서도 어댑터를 쓸 수 있다는 장점이 있음.

 

 

Façade Pattern

어떤 서브 시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공. 퍼사드에서 고수준 인터페이스를 정의하기 때문에 서브 시스템을 더 쉽게 사용 가능.

 

Class Diagram

 

Principle of Least Knowledge

정말 친한 친구와 얘기하라.

 

특징

• 서브시스템의 구성 요소를 보호 할 수 있다.
• 서브시스템과 클라이언트 코드 간의 결합도를 줄일 수 있다.
• 서브시스템 클래스를 사용하는 것을 완전히 막지는 않는다.

 

Template Method Pattern

알고리즘의 각 단계들을 정의하며, 그 중 한 개 이상의 단계가 서브클래스에 의해 제공되는 경우에 사용.

AbstractClass에서 알고리즘의 골격을 정하고, 서브클래스에서 특정 메서드를 구현.

Hook

알고리즘의 특정 부분이 선택적으로 적용된다는가 하는 경우에 사용.

 

Class Diagram

 

Hollywood Principle

먼저 연락하지 마세요. 저희가 연락 드리겠습니다.

이를 활용하면, 의존성 부패를 방지 할 수 있음.

 

Iterator Pattern

Collection 구현 방법을 노출시키지 않으면서도 그 집합체 안에 들어있는 모든 항목에 접근할 수 있는 방법을 제공.

모든 항목에 일일이 접근하는 작업을 컬렉션 객체가 아닌 반복자 객체에서 맡게 된다. 이렇게 하면 집합체의 인터페이스 및 구현이 간단해질뿐 아니라, 집합체에서는 반복작업에서 손을 떼고 원래 자신이 할 일에만 전념할 수 있음.

 

Class Diagram

 

 

 

Single Responsibility Principle

클래스를 변경하는 목적은 단 하나여야 한다.

 

 

Composite Pattern

객체들을 트리 구조로 구성하여 부분과 전체를 나타내는 계층구조로 만들 수 있음.

Class Diagram

특징

• 클라이언트에서 단일 객체와 복합 객체를 똑같은 방법으로 다룰 수 있음.
• 메뉴와 메뉴 항목을 같은 구조에 집어 넣어서 부분-전체 계증구조를 생성 할 수 있음. 컴포지트를 따르는 디자인을 사용하면 간단한 코드만 가지고도 똑 같은 작업을 전체 메뉴 구조에 대해서 반복해서 적용할 수 있음.
• 단일 책임 원칙을 깨면서 대신에 투명성을 확보
• 가장 큰 장점 : Client를 단순화시킬 수 있음

 

State Pattern

OCP, 위임, DIP
객체의 내부상태에 따라  스스로 행동을 변경할 수 있게끔 허가하는 패턴.
상태가 변할 때마다 서브클래스 중 하나의 인스턴스로 변경함.
 
장점으로는 한 State와 관계된 모든 동작들이 하나의 Object 안에 모두 모인다.
State 추가 시 다른 Object에 대한 수정 없이 하나의 Object만 추가되면 된다.
따라서 State에 따른 조건문 없이 관리가 가능하다.
단점으로는 State 수만큼 Object가 관리되어야 함으로 Object가 늘어나고,
State 안에 동작이 추가될 경우 모든 Object들에 대해서 추가되어야 해서 수정범위가 늘어나게 된다.

 

Proxy Pattern

어떤 다른 객체로 접근하는 것을 통제하기 위해서 그 객체의 대리자(Surrogate) 또는 Placeholder를 제공하는 패턴.

 

Proxy pattern의 활용되는 방식

Real subject가 필요한 경우에 생성될 수 있도록 컨트롤 하거나 생성되기 전까지 대리인 역할을 한다. Real subject가 생성되면 Client로부터의 요청사항을 Real subject로 전달한다.
Client와 Real subject가 서로 다른 주소체계에 있거나 Real subject가 생성하는데 오래걸리거나 비싸거나, Real subject에 접근하는 권한의 관리가 필요할 경우 활용된다.

- remote proxy : responsible for encoding a request and its arguments and for sending the encoded request to the real subject in a different address space – 
- virtual proxy : may cache additional information about the real subject so that they can postpone accessing it – 
- protection proxy : checks that the caller has the access permissions required to perform a request

원격 프록시 : 요청과 해당 인수를 인코딩하고 인코딩된 요청을 다른 주소 공간의 실제 주체에게 보내는 역할을 합니다.
- 가상 프록시 : 실제 주제에 대한 추가 정보를 캐시에 저장하여 액세스를 연기할 수 있습니다.
- 보호 프록시 : 호출자가 요청을 수행하는 데 필요한 액세스 권한이 있는지 확인합니다.

 

Visitor Pattern

객체 구조를 이루는 원소에 대해 수행할 연산을 표현하는 패턴.
연산을 적용할 원소의 클래스를 변경하지 않고도(구조 변경 없이) 새로운 연산을 정의(새로운 기능 추가)할 수 있게 합니다. 다양한 객체에 새로운 기능을 추가해야 하는데 캡슐화가 별로 중요하지 않은 경우에 사용.
데이터 구조와 처리를 분리하자. 
– 데이터 구조를 돌아다니는 “방문자”를 정의해서, 이 방문자가 “처리”를 담당하도록 하자. 
– 새로운 처리를 추가하고 싶을 때는, 새로운 “방문자”를 만든다.

 

Mediator Pattern

중재자가 복잡하게 얽혀있는 객체들 간의 상호 통신을 중재시키고, 객체들 간의 상호 작용 로직을 Mediator에 집중시킴으로써 처리를 원할하게 한다.

중재자 패턴은
복잡한 M개의 객체 사이에 N개의 관계가 형성되어 있을 때
M개의 객체 사이에 중재자를 하나 넣어서
이를 M:1 관계로 바꿔준다.

 

주요 컴포넌트

Mediator

• Colleague 역할들과의 통신을 조정하기 위한 인터페이스를 정하는 역할

ConcreteMediator

• Mediator 구체 클래스.

Colleague

• Mediator 역할과 통신을 할 인터페이스를 정함

ConcreteColleague

• Colleague 구체 클래스.
• ex) ColleagueButton, ColleagueTextField 

 

Builder Pattern

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

Bridge Pattern

구현부에서 추상층을 분리하여 각자 독립적으로 변형할 수 있게 하는 패턴.
추상적 개념과 이에 대한 구현 사이의 지속적인 종속 관계를 피하고 싶을 때 사용. 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 통해 확장되어야 할때 사용.

Chain of Responsibility Pattern

책임 떠넘기기 패턴.

어떤 요구가 발생했을 때 그 요구를 처리할 객체를 바로 결정할 수 없는 경우에는 다수의 객체를 사슬처럼 연결해 두고 객체의 사슬을 차례로 돌아다니면서 목적에 맞는 객체를 결 정하는 경우

 

요구하는 사람과 요구를 처리하는 사람을 느슨하게 연결

• Client 는 맨 처음 사람에게만 요구를 한다
• 그 요구가 처리자들을 연결한 사슬을 돌아다니다가 적절한 처리자에 의해 처리된다
  이 패턴을 사용하지 않으면 , 이 요구는 이 처리자가 처리해야 한다 라는 지식을 누군가 중앙 집중적으로 가지고 있어야 한다. 이 지식을 요구자에게 맡기는 것은 현명하지 않다.

동적으로 처리자들의 순서를 바꿀 수 있다.

자신의 일에 집중할 수 있다.

유연성은 높지만, 처리 속도는 느린 단점.

 

Flyweight Pattern

크기가 큰 객체가 여러 개 있을 때, 공유를 통해 이들을 효율적으로 지원하는 패턴. 해쉬 테이블에 자주 사용되고 반복적이며 메모리가 큰 것을 저장해두고 재사용하는것

인스턴스를 가능한 한 공유시켜서, 쓸데없이 new를 하지 않도록 한다. – 인스턴스가 필요할 때 마다 new를 하는 것이 아니라, 이미 만들어져 있는 인스턴스를 이용할 수 있으면 공유하자. 
Prototype은 복제를 하는 것이고 Flyweight는 있는것 그대로 쓴다.

 

Prototype Pattern

생성할 객체의 종류를 명시하는 데에 원형이 되는(Prototypical) 인스턴스를 이용하고, 그 원형을 복사함으로써 새로운 객체를 생성하는 패턴.
클래스로부터 인스턴스를 새로 만드는 것이 아니라, 현재 존재 하는 인스턴스를 복사(복제)해서 새로운 인스턴스를 만들 필요 가 있을 때, 이 작업을 편하게 하기 위해 사용한다

pros : 인스턴스를 만드는 복잡한 과정을 몰라도 되고 속도가 빠르다
cons : 복사본 자체를 만드는일 자체가 복잡할 수 있다.

객체를 빨리 생성하는 패턴

 

Memento Pattern

현재 객체의 상태를 기록하여 보존하기 위한 Memento 패턴 
– Caretaker 역할은 중간 중간 Originator 역할에게 부탁하여 ‘현 재의 상태’를 표현하는 Memento 역할을 만든다. 
– Caretaker 역할은 필요할 때 서랍 안에서 Memento 역할을 꺼 내서 Originator 역할에게 건네주면, 그 상태로 복원이 된다.