1. 문법 규칙을 클래스로 표현, Interpreter 패턴
(1) Interpreter 패턴의 개념 및 사용 목적
| 개념 | 사용 목적 |
|---|---|
| 자주 등장하는 문제를 간단한 언어의 문법으로 정의하고 해석하여 재사용하는 행동 디자인 패턴 | – 자주 등장하는 패턴을 문법/언어로 정의 – 기존 코드 변경없이 새로운 표현 생성 |
(2) Interpreter 패턴의 클래스 다이어그램
(3) Interpreter 패턴의 구성요소
| 구성요소 | 역할 |
|---|---|
| AbstractionExpression | 상 구문 트리에 속한 모든 노드에 해당하는 클래스들이 공통으로 가져야 할 Interprete() 연산을 추상 연산으로 정의 |
| TerminalExpression | 문법에 정의한 터미널 기호와 관련된 해석 방법 구현 |
| NonterminalExpression | 문법에 나타나는 모든 기호에 대해서 클래스를 정의하고 터미널 기호가 아닌 모든 기호들에 대해서 Interprete() 연산을 구현 |
| Context | 인터프리터가 구문 해석 하기위한 정보를 제공하여 번역기에 대한 포괄적인 정보를 포함 |
2. 하위 클래스에서 구체적 처리, Template method 패턴
(1) Template method 패턴의 개념 및 사용 목적
| 개념 | 사용 목적 |
|---|---|
| 상위 클래스에서 처리의 뼈대를 결정하고 하위 클래스에서 구체적인 내용을 결정하는 행동 디자인 패턴 | – 구체적으로 처리할 클래스의 템플릿 제공 – 추상 메소드의 공통 알고리즘을 재사용 |
(2) Template method 패턴의 클래스 다이어그램
(3) Template method 패턴의 구성요소
| 구성요소 | 역할 |
|---|---|
| AbstractClass | 템플릿 메소드를 구현하며, 그 템플릿 메소드에서 사용할 추상 메소드 선언 |
| ConcreteClass | AbstractClass에서 정의된 추상 메소드를 구체적으로 구현 |
3. 책임 전가 구조, Chain of Responsibility 패턴
(1) Chain of Responsibility 패턴의 개념 및 사용 목적
| 개념 | 사용 목적 |
|---|---|
| 객체 간 결합을 느슨하게 하기 위해 클라이언트로부터의 요청을 처리할 수 있는 처리 객체를 집합(Chain)으로 만들어 부여하는 행동 디자인 패턴 | – 객체 간 연계를 통해 처리 가능 객체 결정 – 객체 간 결합도를 낮추어 독립적으로 수행 |
(2) Chain of Responsibility 패턴의 클래스 다이어그램
(3) Chain of Responsibility 패턴의 구성요소
| 구성요소 | 역할 |
|---|---|
| Handler | 요구 처리 인터페이스를 정의하고 처리할 다음 객체 준비, 스스로 처리 불가 시 다음 객체로 연결 |
| ConcreteHandler | 요청을 구체적으로 처리하며, 각 Handler는 요청에 따라 처리 혹은 체인 전달을 결정 |
4. 명령을 클래스로 표현, Command 패턴
(1) Command 패턴의 개념 및 사용 목적
| 개념 | 사용 목적 |
|---|---|
| 요청을 요청에 대한 모든 정보가 포함된 독립실행형 객체로 변환하여 명령 객체 필요에 따라 처리하는 행동 디자인 패턴 | – 실행 기능 캡슐화로 여러 기능 실행 재사용성 확보 – 기능 수정/변경 시 클래스만 정의하여 유연한 확장성 제공 |
(2) Command 패턴의 클래스 다이어그램
(3) Command 패턴의 구성요소
| 구성요소 | 역할 |
|---|---|
| Command | 실행될 기능에 대한 인터페이스. 실행될 기능을 execute()로 정의 |
| ConcreteCommand | 실행되는 기능을 구현하는 클래스. Receiver가 무엇을 처리해야 하는지(execute() 세부 구현) 정의 |
| Receiver | ConcreteCommand에서 execute()를 구현할 때 필요한 클래스. ConcreteCommand의 기능을 실행하기 위해 사용하는 수신자 클래스 |
| Invoker | 기능의 실행을 요청하는 호출자 클래스. Client의 요청을 받아 Receiver의 액션을 호출 |
5. 반복 처리, Iterator 패턴
(1) Iterator 패턴의 개념 및 사용 목적
| 개념 | 사용 목적 |
|---|---|
| 집합 내 모든 컬렉션(항목)에 대해 순서대로 전체를 검색하고 처리를 반복하는 행동 디자인 패턴 | – 구현 방법 노출 없이 모든 항목에 접근 – 내부 구현에 관계없이 객체에 접근, 반복 처리 |
(2) Iterator 패턴의 클래스 다이어그램
(3) Iterator 패턴의 구성요소
| 구성요소 | 역할 |
|---|---|
| Iterator | 컬렉션(항목)의 요소들을 순서대로 검색하기 위한 인터페이스를 선언 |
| ConcreteIterator | Iterator에서 컬렉션 순회를 위한 특정 알고리즘들을 구현 |
| Aggregate | 여러 요소들로 구성된 컬렉션 인터페이스를 선언 |
| ConcreteAggregate | Aggregate에서 인터페이스를 구현 |
6. 중재자를 통해 처리, Mediator 패턴
(1) Mediator 패턴의 개념 및 사용 목적
| 개념 | 사용 목적 |
|---|---|
| 모든 객체간의 복잡한 상호작용을 캡슐화하고 하나의 클래스에 위임하여 처리하는 행위 디자인 패턴 | – 객체 관계 복잡도를 낮추어 유지보수 및 확장성 제공 – 객체간 상호작용을 중재자가 관리하여 느슨한 결합 유지 |
(2) Mediator 패턴의 클래스 다이어그램
(3) Mediator 패턴의 구성요소
| 구성요소 | 역할 |
|---|---|
| Mediator | Colleague 객체 간의 상호참조를 위한 인터페이스로 클라이언트 등록, 실행 등의 메소드 정의 |
| ConcreteMediator | Colleague 간의 상호참조를 조정하는 Mediator의 인터페이스 구현 |
| Colleague | 다른 Colleague와의 상호참조를 위한 인터페이스로 Mediator와 통신하는 인터페이스 정의 |
| ConcreteColleague | Mediator를 통해 다른 Colleague와의 상호참조하는 Colleague 인터페이스 구현 |
7. 상태 저장/복원, Memento 패턴
(1) Memento 패턴의 개념 및 사용 목적
| 개념 | 사용 목적 |
|---|---|
| 객체의 구현 세부 사항을 공개하지 않으면서 해당 객체의 이전 상태를 저장하고 복원할 수 있게 해주는 행동 디자인 패턴 | – undo, redo, history, snapshot 기능 제공 – 사용자가 원하는 시점의 데이터를 복원 |
(2) Memento 패턴의 클래스 다이어그램
(3) Memento 패턴의 구성요소
| 구성요소 | 역할 |
|---|---|
| Originator | 자신의 상태에 대한 스냅샷(Memento)을 생성할 수 있으며, 필요시 스냅샷에서 자신의 상태를 복원 |
| Memento | Originator의 상태의 스냅샷 역할을 하는 값 객체, Memento는 불변으로 만든 후 생성자를 통해 데이터를 한 번만 전달 |
| CareTaker | Memento의 스택을 저장하여 Originator의 기록을 추적하며, 복원 시 최상단 Memento를 스택에서 가져와 Originator의 복원 메소드에 전달 |
8. 상태 변화 알림, Observer 패턴
(1) Observer 패턴의 개념 및 사용 목적
| 개념 | 사용 목적 |
|---|---|
| 관찰 중인 객체에 발생하는 모든 이벤트에 대하여 알리는 구독 메커니즘을 정의하는 행동 디자인 패턴 | – 분산 이벤트 핸들링 시스템 구현 시 사용 – 이벤트 기반 아키텍처 등 외부 이벤트에 응답 |
(2) Observer 패턴의 클래스 다이어그램
(3) Observer 패턴의 구성요소
| 구성요소 | 역할 |
|---|---|
| Observer | Subject로부터 상태 변화를 전달받는 알림 인터페이스를 선언하며 대부분의 경우 단일 update 메소드로 구성 |
| Subject | 관찰되는 대상으로, Observer를 등록하는 메소드와 삭제하는 메소드로 구성 |
| ConcreteObserver | 구체적인 Observer로 update 메소드 호출 시 그 메소드 내 Subject의 현재 상태를 취득 |
9. 상태를 클래스로 표현, State 패턴
(1) State 패턴의 개념 및 사용 목적
| 개념 | 사용 목적 |
|---|---|
| 객체의 내부 상태가 변경될 때 해당 객체가 그의 행동을 변경할 수 있도록 하는 행동 디자인 패턴 | – 상태를 클래스로 표현, 클래스 전환으로 상태 변화를 표현 – 유한 상태 기계(유한 오토마타)의 접근 방식을 객체에 적용 |
(2) State 패턴의 클래스 다이어그램
(3) Template method 패턴의 구성요소
| 구성요소 | 역할 |
|---|---|
| State | 상태를 나타내며, 상태마다 다르게 동작하여 상태에 의존한 동작을 하는 메소드 선언 |
| ConcreteState | 구체적인 각각의 상태를 나타내며, State에서 선언된 메소드를 구체적으로 구현 |
| Context | 현재 상태를 나타내는 ConcreteState를 가지며, State 패턴 사용자에게 필요한 인터페이스를 정의 |
10. 알고리즘 전환, Strategy 패턴
(1) Strategy 패턴의 개념 및 사용 목적
| 개념 | 사용 목적 |
|---|---|
| 알고리즘의 패밀리를 정의하고, 각 패밀리를 별도의 클래스에 넣은 후 그 객체들을 상호교환 하는 행동 디자인 패턴 | – 특정 작업을 다양한 방식(알고리즘)으로 수행 – 같은 문제를 다른 방법으로 쉽게 해결 지원 |
(2) Strategy 패턴의 클래스 다이어그램
(3) Strategy 패턴의 구성요소
| 구성요소 | 역할 |
|---|---|
| Strategy | 모든 ConcreteStrategy의 공통 부분이며, Context가 Strategy을 실행하는데 사용하는 메소드를 선언 |
| ConcreteStrategy | Context가 사용하는 알고리즘의 다양한 변형을 구현 |
| Context | ConcreteStrategy 중 하나에 대한 참조를 유지하고 Strategy 인터페이스를 통해서 이 객체와 통신 |
11. 데이터 구조와 처리를 분리, Visitor 패턴
(1) Visitor 패턴의 개념 및 사용 목적
| 개념 | 사용 목적 |
|---|---|
| 구조를 수정하지 않고 신규 동작 추가를 위해 객체에서 데이터 구조와 처리를 분리하는 행동 디자인 패턴 | – 알고리즘 동작 객체에서 데이터 구조와 처리 분리 – 객체 구조 수정 없이 새로운 동작 추가 |
(2) Visitor 패턴의 클래스 다이어그램
(3) Visitor 패턴의 구성요소
| 구성요소 | 역할 |
|---|---|
| Visitor | ObjectStructure의 ConcreteElement를 인수들로 사용할 수 있는 Visitor 메소드 집합을 선언 |
| ConcreteVisitor | 각 ConcreteElement 마다 작성된 같은 처리의 여러 버전을 구현 |
| Element | Visitor가 방문할 곳을 나타내며, Visitor를 받아들이는 ‘accept’ 메소드를 선언 |
| ConcreteElement | 반드시 accept 메소드를 구현하여 호출을 현재 Element 클래스에 해당하는 적절한 Visitor 메소드로 리다이렉트 |
| ObjectStructure | Element 집합을 다루며, ConcreteVisitor가 각 Element를 취급할 수 있는 메소드 보유 |
[참고]
- 영진닷컴, JAVA 언어로 배우는 디자인 패턴 입문: 쉽게 배우는 GoF의 23가지 디자인 패턴