Design Pattern - Behavioral Pattern

프로그램의 Runtime Behaivor에 관심을 갖습니다.
객체가 수행하는 역할이나 이러한 객체들 간의 Interact하는 방법을 정의합니다.

1. 변하는 것을 Encapsulation 한다.

• Strategy
• State
• Mediator
• Iterator

2. 객체가 Argument로 사용된다.

• Visitor
• Command

3. Sender와 Receiver를 Decoupling 시킨다.

• Command
• Observer
• Mediator
• Chain of Responsibility

4. 그 외

• Template Method
• Interpreter
• Memento

1. Strategy

제공 될 수 있는 각 Behaivor를 Encapsulation하고 Behaivor 별 확장이 용이하여 유지보수 성이 높으며, Composition과 Delegation을 통해 Runtime에 Behaivor를 선택하고 교체할 수 있게 됩니다. OO Principle에서는 OCP와 연관 되며, 기능 확장에는 열려 있고 변경은 폐쇄되어 있습니다.

2. State

상태(State) 기반의 Behavior를 캡슐화하고 현재 상태(State)에게 모든 Behavior를 위임합니다. 객체의 Behavior가 상태에 의존되고 Runtime에 상태에 따라 Behavior가 변경될 수 있을 때 사용합니다. 

3. Mediator

https://github-wiki-see.page/m/jeuxdeau/gof-design-patterns/wiki/Behavioral:-5.-Mediator

서로 관련된 객체 사이의 복잡한 통신과 제어를 한 곳으로 집중시키고자 하는 경우 사용되는 패턴 입니다. 서로 밀접하게 연관되어 있는 객체들 간 의존관계를 분리하고 미디에이터에게 모든 제어 흐름을 위임하게 됩니다. 각 객체를 분시리킴으로써 각 모듈의 재사용성을 획기적으로 향상시킬 수 있고, 제어 로직을 한 군데 모아놓아 관리가 수월해 집니다.

4. Iterator

 

5. Visitor

https://ehclub.co.kr/1285

데이터 구조와 로직을 분리하여 데이터 구조의 원소들을 변경하지 않고 새로운 로직을 추가할 수 있는 패턴입니다. 새로운 로직을 추가하려면 새로운 Visitor를 추가하기만 하면 됩니다. 객체 구조는 덜 변하고 Operation이 자주 바뀔 때 사용합니다. 관련 있는 Operation은 모으고 관련 없는 Opertaion은 분리하여 Cohesion을 높이고 OCP를 달성 합니다. 캡슐화가 적용되지 않으며 Concrete Element를 추가하기 어려운 단점이 있습니다.

6. Command

요구사항을 객체로 캡슐화 할 수 있으며, 매개변수를 써서 여러 가지 다른 요구 사항을 집어넣을수도 있습니다. 또한 요청 내용을 큐에 저장하거나 로그로 기록할수도 있으며, 작업취소 기능도 지원합니다. Invoker와 Concreate Command를 Decouple 하여 Command 확장을 용이하게 합니다.

예제보기

7. Observer

상태 변화가 발생했을 때 객체가 Notify 받을 수 있도록 허락 합니다.

8. Chain of Responsibility

일련의 Handler 가 존재하고, 사용자 요청에 대해 처리를 하며, 다음 handler에게 요청을 위임합니다.  

9. Template Method

서브 클래스들이 알고리즘 내에 Implement 단계를 결정 합니다.

10. Interpreter

어떤 언어에 대한 인터프리터를 만들 때 사용 합니다. 각 문법 규칙을 클래스로 표현하기 때문에 언어를 쉽게 구현할 수 있습니다. 문법이 클래스에 의해 표현되기 때문에 언어를 쉽게 변경하거나 확장할 수 있습니다.

11. Memento

객체를 이전 상채로 복구시켜야 하는 경우에 해당 패턴을 사용 합니다. 작업 취소와 같은 요청을 구현하기 쉬우며, 저장된 객체를 핵심 객체와는 다른 별도의 객체에 보관하기 때문에 안전합니다.