위키원
"행동패턴"의 두 판 사이의 차이
| 6번째 줄: | 6번째 줄: | ||
위 그림을 보면 Sender 객체가 Handler 객체에 요청을 하며 그 요청이 수행되는 구조와 일련의 과정들이 나타나 있다.<br> | 위 그림을 보면 Sender 객체가 Handler 객체에 요청을 하며 그 요청이 수행되는 구조와 일련의 과정들이 나타나 있다.<br> | ||
왼쪽의 class diagram을 통해서 Handler 클래스를 상속하고 있는 다른 처리 클래스가 존재한다는 것을 알 수 있고, 오른쪽의 Sequence diagram을 통해서 그 과정이 Handler 클래스를 상속하고 있는 Receiver 1,2,3 클래스의 객체로 이루어진다는 것을 알 수 있다.<br><br> | 왼쪽의 class diagram을 통해서 Handler 클래스를 상속하고 있는 다른 처리 클래스가 존재한다는 것을 알 수 있고, 오른쪽의 Sequence diagram을 통해서 그 과정이 Handler 클래스를 상속하고 있는 Receiver 1,2,3 클래스의 객체로 이루어진다는 것을 알 수 있다.<br><br> | ||
| − | 이 패턴은 자바의 Exception Handling과 같은 원리인데 try문으로 코드를 실행시켜서 안되면 이어지는 catch문들이 그것을 처리하고 마지막에 finally가 처리한다는 면에서 비슷하다고 보는 것이다.<ref name='chain'>귤덕, 〈[https://sexycoder.tistory.com/105 Chain of Responsibility Pattern (책임 사슬 패턴) ]〉</ref> | + | 이 패턴은 자바의 Exception Handling과 같은 원리인데 try문으로 코드를 실행시켜서 안되면 이어지는 catch문들이 그것을 처리하고 마지막에 finally가 처리한다는 면에서 비슷하다고 보는 것이다.<ref name='chain'>귤덕, 〈[https://sexycoder.tistory.com/105 Chain of Responsibility Pattern (책임 사슬 패턴) ]〉, 2018-03-02</ref> |
| − | |||
=== 커맨드(Command) 패턴=== | === 커맨드(Command) 패턴=== | ||
| − | + | 커맨드 패턴은 사용자가 요구하는 명령어를 객체에 캡슐화(encapsulation)하여 저장한다. 각각의 명령어에 해당하는 객체는 그 명령어에 해당하는 기능을 실행하며, 필요에 따라 '명령 취소' 기능을 제공한다. 명령어와 관련된 사항이 객체에 캡슐화되어 있기 때문에, 사용자들은 단순히 그 명령어 객체를 생성해서 사용하기만 하면 된다. 또한, 이러한 명령어 객체들은 모두 공동의 상위 클래스를 갖고 있다. 이 상위 클래스는 각 명령어 객체의 클래스가 구현해야 할 메소드를 정의하고 있다. 예를 들어, 워드 프로세서에서 사용되는 '복사', '잘라내기', '붙여넣기'에 해당하는 명령어 클래스를 각각 CopyCommand, CutCommand, PasteCommand 라고 하고 이 세 클래스가 상속받는 추상 클래스를 AbstractCommand 라고 하면 전체적인 클래스 사이의 관계는 다음 그림과 같을 것이다.<br> | |
| + | [[파일:command_pattern.gif]] | ||
=== 인터프리터(Interpreter) 패턴 === | === 인터프리터(Interpreter) 패턴 === | ||
주어진 언어에 대해서 문법을 위한 표현수단을 정의하고, 해당 언어로 된 문장을 해석하는 해석기를 사용하는 패턴이다. | 주어진 언어에 대해서 문법을 위한 표현수단을 정의하고, 해당 언어로 된 문장을 해석하는 해석기를 사용하는 패턴이다. | ||
2020년 8월 14일 (금) 15:03 판
행동 패턴(Behavioral patterns)은 오브젝트 사이의 상호작용과 오브젝트의 역할(책임)에 대한 것이다. 행위 패턴이라고도 한다.[1]
목차
종류
Chain of Responsibility 패턴
여러 개의 객체 중에서 어떤 것이 요구를 처리할 수 있는지를 사전에 알 수 없을 때 사용된다. 즉 요청 처리가 들어오게 되면 그것을 수신하는 객체가 자신이 처리 할 수 없는 경우에는 다음 객체에게 문제를 넘김으로써 최종적으로 요청을 처리 할 수 있는 객체의 의해 처리가 가능하도록 하는 패턴이다.
위 그림을 보면 Sender 객체가 Handler 객체에 요청을 하며 그 요청이 수행되는 구조와 일련의 과정들이 나타나 있다.
왼쪽의 class diagram을 통해서 Handler 클래스를 상속하고 있는 다른 처리 클래스가 존재한다는 것을 알 수 있고, 오른쪽의 Sequence diagram을 통해서 그 과정이 Handler 클래스를 상속하고 있는 Receiver 1,2,3 클래스의 객체로 이루어진다는 것을 알 수 있다.
이 패턴은 자바의 Exception Handling과 같은 원리인데 try문으로 코드를 실행시켜서 안되면 이어지는 catch문들이 그것을 처리하고 마지막에 finally가 처리한다는 면에서 비슷하다고 보는 것이다.[2]
커맨드(Command) 패턴
커맨드 패턴은 사용자가 요구하는 명령어를 객체에 캡슐화(encapsulation)하여 저장한다. 각각의 명령어에 해당하는 객체는 그 명령어에 해당하는 기능을 실행하며, 필요에 따라 '명령 취소' 기능을 제공한다. 명령어와 관련된 사항이 객체에 캡슐화되어 있기 때문에, 사용자들은 단순히 그 명령어 객체를 생성해서 사용하기만 하면 된다. 또한, 이러한 명령어 객체들은 모두 공동의 상위 클래스를 갖고 있다. 이 상위 클래스는 각 명령어 객체의 클래스가 구현해야 할 메소드를 정의하고 있다. 예를 들어, 워드 프로세서에서 사용되는 '복사', '잘라내기', '붙여넣기'에 해당하는 명령어 클래스를 각각 CopyCommand, CutCommand, PasteCommand 라고 하고 이 세 클래스가 상속받는 추상 클래스를 AbstractCommand 라고 하면 전체적인 클래스 사이의 관계는 다음 그림과 같을 것이다.
인터프리터(Interpreter) 패턴
주어진 언어에 대해서 문법을 위한 표현수단을 정의하고, 해당 언어로 된 문장을 해석하는 해석기를 사용하는 패턴이다.
Iterator 패턴
내부 표현부를 노출하지 않고 어떤 객체 집합의 원소들을 순차적으로 접근할 수 있는 방법을 제공하는 패턴이다.
Mediator 패턴
한 집합에 속해있는 객체들의 상호 작용을 캡슐화하는 객체를 정의하는 패턴이다. 중재자는 객체들이 직접 서로 참조하지 않도록 함으로써 객체들 간의 느슨한 연결을 촉진시키며 객체들의 상호작용을 독립적으로 다양화시킬 수 있도록 해준다.
옵저버(Observer) 패턴
객체들 사이에 1 : N 의 의존관계를 정의하여 어떤 객체의 상태가 변할 때, 의존관계에 있는 모든 객체들이 통지받고 자동으로 갱신될 수 있게 만드는 패턴이다.
상태(State) 패턴
객체의 내부 상태가 변경될 때 행동을 변경하도록 허락한다. 객체는 자신의 클래스가 변경되는 것처럼 보이게 된다.
스트레이트지(Strategy) 패턴
동일 계열의 알고리즘들을 정의하고 각각 캡슐화하며 이들을 상호교환 가능하도록 만드는 것이다. 알고리즘을 사용하는 사용자로부터 독립적으로 알고리즘이 변경될 수 있도록 하는 패턴이다.
템플릿(Template) 패턴
객체의 연산에서 알고리즘의 뼈대만 정의하고, 나머지는 서브클래스에서 이루어지게 하는 패턴이다. 템플릿 패턴은 알고리즘의 구조는 변경하지 않고 알고리즘의 각 단계를 서브클래스에서 재정의하게 된다.
비지터(Visitor) 패턴
객체구조를 이루는 원소에 대해 수행할 연산을 표현한다. 방문자는 연산에 적용할 원소의 클래스를 변경하지 않고 새로운 연산을 재정의 할 수 있다.
각주
- ↑ 도킨샤, 〈Chapter 1.디자인 패턴 소개 〉, 2020-01-07
- ↑ 귤덕, 〈Chain of Responsibility Pattern (책임 사슬 패턴) 〉, 2018-03-02
