행동 패턴 ( Behavioral pattern )
어떤 처리의 책임을 어느 객체에 할당하는 것이 좋은지.
알고리즘을 어느 객체에 정의하는 것이 좋은지등을 다룬다.
객체나 클래스에 대한 패턴을 정의하는 것이 아니고, 그들 간의 교류방법에 대하여 정의하는 것이 주된 논의 사항이다.
이 행동패턴을 사용하면 우리는 객체간의 제어 구조보다는 객체들을 어떻게 연결시킬 것인지에 더 중점을 두는 패턴이다.
행동 클래스 패턴(Behavioral class pattern)은 클래스 사이에 행동 책임을 분산하기 위해서 상속을 사용한다. 템플릿 메소드 패턴은 간단하며, 일반적인 패턴이다. 템플릿 메서드는 알고리즘에 대한 추상화된 정의로 알고리즘을 한 단계씩 정의한다. 각 단계는 추상연산 또는 기본연산 중 하나이다. 기본 연산은 자신이 처리 내용을 정의하고, 구현 내용을 확정한 연산을 뜻한다.
추상 메서드의 실제 구현은 서브클래스가 한다.
해석자패턴은 문법을 클래스 계통으로 구성하고, 이 클래스들의 인스턴스에 대한 연산으로서 해석자를 구현한다.
행동 객체 패턴(Behavioral object pattern )은 상속보다는 복합을 통해서 객체 사이에 행동 처리의 책임을 분산시킨다. 즉 하나의 객체가 스스로 모든 처리를 하는 것이 아니라, 관련된 객체들이 하나의 처리를 책임지는 방법이다.
중재자 패턴은 관련된 객체 집합 사이의 중재로 새로운 객체를 도입함으로써 이 솽황을 피한다. 중재자 객체가 간결하던지.
이 중재자를 도입함으로써 이 상황을 피하게 해준다.
이 중재자 객체가 관련 객체 간의
처리를 담당함으로써 객체 간의 결합도가 느슨해질 수 있다.
책임 연쇄 패턴은 결합도를 좀 더 약화시키는 효과를 준다.
한 객체에게 보낸 메시지가 내부적으로 연결된 다른 객체에 자동으로 전달 된다. 그리고 메시지를 받은 객체는 런타임 조건에 따라서 메시지를 처리할 것인지 결정하게 된다. 이렇게 고리로 연결할 수 있는 객체 수는 제한이 없으며, 연결된 객체 중 하나를 런타임에 선택할 수 있다.
감시자 패턴은 객체간의 종속성을 정의하고 관리하는 패턴이다. 이 것은 사용한 가장 오래된 예는 smalltalk의 MVC개념을 들 수 있다.
전략 패턴은 알고리즘을 객체로 만들어 그것을 캡슐화한다. 알고리즘을 별도의 객체로 분리함으로써 알고리즘이 바뀔 때 해당 알고리즘 객체를 변경 또는 추가하고 이를 사용하는 원래 객체로 바뀐 객체를 참조하게 하거나, 아무 변화를 느끼지 못하고 사용하도록 해준다.
명령패턴은 요청 자체를 객체로 만들어서 이 객체를 매개변수로 넘기거나 수행한 명령 리스트에 저장하는 방식으로 사용할 수 있다.
상태패턴은 객체의 상태를 또 다른 객체로 정의하여 객체의 상태가 바뀌면 이에 대항하는 객체를 변경할 수 있다.
방문자 패턴은 하나의 행동을 여러 클래스에 걸쳐서 분산할 수 있게 한다. 반복자 패턴은 모든 객체들을 순회하거나 차례대로 접근하는 방법을 제공한다.
책임 연쇄( Chain of Responsibility )
의도
- 메시지를 보내는 객체와 이를 받아 처리하는 객체들 간의 결합도를 없애기 위한 패턴이다. 하나의 요청에 대한 처리가 반드시 한 객체에서만 되지 않고, 여러 객체에게 그 처리 기회를 주려는 것이 목적이다.
동기
- 이 패턴의 아이디어는 메시지 송신측과 수신측을 분리하기 위한 것이다.
활용
* 이런 상황에서 사용 하면 좋다.
- 하나 이상의 객체가 요청을 처리해야 하고, 그 요청 처리자 중 어떤 것이 선행자인지 모를 때, 처리자가 자동으로 확정 되어야 한다.
- 메시지를 받을 객체를 명시하지 않은 채 여러 객체 중 하나에게 처리를 요청하고 싶을 때
- 요청을 처리할 수 있는 객체 집합이 동적으로 정의되어야 할 때
결과
1. 객체 간의 행동적 결합도가 적어진다.
2. 객체에게 책임을 할당하는데 유연성을 높일 수 있다.
3. 메시지 수신이 보장되지는 않는다.
명령 ( Command ) | Action | Transaction
의도
- 요청 자체를 캡슐화 하는 것이며, 이를 통해 요청이 서로 다른 사용자를 매개변수로 만들고, 요청을 대기시키거나, 로깅하며, 되돌릴 수 있는 연산을 지원한다.
동기
- 가끔 요청 받은 연산이 무엇이며, 이를 처리 할 객체가 누군지에 대해 아무런 정보 없이 임의의 객체에 메시지를 보내야 할 때가 있을 때를 위해 사용한다.
활용
* 이런 상황에서 사용 하면 좋다.
- 수행할 동작을 객체로 매개변수화할 떄, 절차지향에서는 이를 Callback 함수로 표현할 수 있다. 명령패턴은 콜백을 객체지향 방식으로 표현한 것이다.
- 서로 다른 시간에 요청을 명시하고, 저장, 실행하고 싶을 때
- 실행 취소 기능을 지원하고 싶을 때
- 시스템이 고장 났을 때 재적용이 가능하도록 변경 과정에 대한 로깅을 지원하고 싶을 때
결과
1. Command는 연산을 호출하는 객체와 연산 수행 방법을 구현하는 객체를 분리한다.
2. Command는 일급 객체로 다른 객체와 같은 방식으로 조작되고 확장 된다.
3. 명령패턴을 여러 개 복합해서 복합 명령을 만들 수 있다.
4. 새로운 Command 객체를 추가하기가 쉽다.
관련
- MacroCommand를 구현하는데에 복합체 패턴 사용 가능.
- 취소를 처리 할 때 객체의 상태를 관리하는데 메멘토 패턴 사용 가능 .
- 명령어가 처리되어 처리된 이력 목록에 저장되기 전에 명령어를 복사해야 한다면, 원형패턴을 사용하면 된다.
해석(Interpreter)
의도
- 어떤 언어에 대해 그 언어의 문법에 대 한 표현을 정의하면서
표현을 사용하여, 해당 언어로 기술된 문장을 해석하는 해석자를 함께 정의 함.
동기
- 특정한 종류의 문제가 자주 발생시 , 간결한 언어를 사용하여 그 문제를 문장으로 표현하는 것이 나을 수 있다.
* 해석자 패턴은 클래스를 이용하여, 각각의 문법이 갖는 규칙을 정의한다.
활용
* 이런 상황에서 사용 하면 좋다.
- 정의할 언어의 문법이 간단하다.
- 효율성은 별로 고려 사항이 아니다.
결과
1. 문법의 변경과 확장이 쉽다.
2. 문법의 구현이 용이하다.
3. 복잡한 문법은 관리하기 어렵다.
4. 표현식을 해석하는 새로운 방법을 추가 할 수 있다.
반복자 ( Iterator ) | Cursor
의도
- 내부 표현부를 노출하지 않고, 집합 객체에 속한 원소들을 순차적으로 접근 할 수 있는 방법을 제공한다.
동기
- List 등, 집합 객체들은 내부 표현 구조를 노출 시키지 않으면서 자신의 원소를 접근 할 수 있는 방법을 제공하는 것이 좋다.
특히나 , 반복자의 개념을 일반화하여 다형성을 지닌 반복이 가능 하도록 하면 좋다.
즉, 사용자는 추상 클래스들만 접근하여, 실제 구체적인 리스트 구현이나 반복 기법에 종속되지 않고, 런타임에 리스트의 구현 방법과 박복자를 변경 할 수 있다.
활용
* 이런 상황에서 사용 하면 좋다.
- 객체 내부 표현 방식을 모르더라도 집합 객체의 각 원소들에 접근 하고 싶을 때
- 집합 객체를 순회하는 다양한 방법을 지원하고 싶을 때
- 서로 다른 집합 객체 구조에 대해서도 동일한 방법으로 순회하고 싶을때
결과
1. 집합 객체의 다양한 순회방법을 제공한다.
예를 들어 파스 트리를 순회 하는데 중위 순회, 후위 순회 같은 것들.
2. Iterator는 Aggregate 클래스의 인터페이스를 단순화 시킨다.
3. 집합 객체에 따라 하나 이상의 순회 방법이 제공 될 수 있다.
관련
- 반복자 패턴은 복합체 패턴과 같이 재귀적 구조가 있을 때 자주 사용한다.
- 다양한 박복자를 사용하여 적당한 Iterator 서브 클래스를 얻으려면 팩토리 메서드 패턴을 사용 할 수 있다.
- 메멘토 패턴도 반복자와 함께 자주 사용 되며, 반복자 자신이 결과를 저장하기 위해 메멘토를 사용한다.
중재자( Mediator )
의도
- 한 집합에 속해있는 객체의 상호작용을 캡슐화하는 객체를 정의한다. 객체들이 직접 서로를 참조하지 않도록 하여 객체 사이의 Loose Coupling을 촉직하며, 개발자가 객체의 상호작용을 독립적으로 다양화 시킬 수 있다.
동기
- 객체지향 개발 방법론에서는 행동을 여러 객체에게 분산시켜 처리하도록 권하고 있다.
활용
* 이런 상황에서 사용 하면 좋다.
- 여러 객체가 잘 정의 된 형태이기는 하나, 복잡한 상호작용을 가질 때
- 한 객체가 다른 객체를 너무 많이 참조하고 많은 의사소통을 수행하여, 그 객체를 재사용하기 힘들 때
- 여러 클래스에 분산된 행동들디 상속이 없이 상활에 맞게 수정 되어야 할 때
결과
1. 서브클래싱을 제한한다.
2. Colleague 객체 사이의 종속성을 줄입니다.
3. 객체 프로토콜을 단순화 시킨다.
4. 객체 간의 협력 방법을 추상화한다.
5. 통제가 집중화된다.
관련
퍼사드 패턴은 객체들로 구성된 서브시스템을 추상화하여 좀 편한 인터페이스를 제공하는 것이고, 퍼사드 객체는 서브시스템을 구성하는 객체로만 메시지가 전달되고, 그 반대로 (서브시스템을 구성하는 객체가 퍼사드 객체에 메시지 전달)는 처리가 되지 않는다. 그러나 중재자의 경우는 양방향 전달이다.
메멘토 ( Memento ) | Token
의도
- 캡슐화를 위배하지 않은 채 어떤 객체의 내부 상태를 잡아내고,실체화 시켜둠으로 이후 해당 객체가 그 상태로 되돌아올 수 있도록 하는 것.
동기
_ 때에 따라서는 객체의 내부 상태를 기록해 둘 필요가 존재한다. * 객체는 자체적으로 상태의 일부나 전부를 캡슐화하여 상태를 외부에 공개하지 않기에 , 다른 객체는 상태에 접근하지 못한다.
메멘토 패턴은 원조본(Originator) 객체가 가진 내부 상태의 스냅샷을 저장하는 객체이다. 즉, 메멘토 이외의 다른 객체에서는 보이지 않는다.
활용
* 이런 상황에서 사용 하면 좋다.
- 어떤 객체의 상태에 대한 스냅샷을 저장 하고, 이 상태로 복귀 해야 할 때
- 필요한 직접적인 인터에시르를 두면 그 객체의 구현 세부 사항이 드러날 수 밖에 없고, 이것으로 인해 객체의 캡슐화가 깨질 때
결과
1. 캡슐화된 경계를 가질 수 있다.
2. Originator 클래스는 단순화 할 수 있다.
3. 메멘토의 사용으로 더 많은 비용이 들어 갈 수 있다.
4. 제한 범위 인터페이스와 광범위 인터페이스를 잘 정의해야 한다.
5. 메멘토를 관리하는데 필요한 비용이 숨어있다.
관련
- 명령 패턴은 실행 취소가 가능한 연산의 상태를 저장 할 때 메멘토 패턴을 사용할 수 있다.
메멘토 패턴은 반복자 패턴에서의 반복 과정 상태를 관리 할 수 이 있다.
감시자 ( Observer ) | Dependent | publish - subscribe
동기
- 하나의 시스템을 서로 연동 되는 클래스 집 합으로 분할 했을 때 발생하는 공통적인 부작용은 관련된 객체 간에 일관성을 유지하도록 해야 한다는 것이다.
활용
* 이런 상황에서 사용 하면 좋다.
- 어떤 추상 개념이 두 가지 양상을 가지고 이를 가지고 재사용 가능.
- 한 객체에 가해진 변경으로 가른 객체를 변경해야하고, 프로그래머들은 얼마나 많은 객체들이 변경되어야 하는지 몰라도 될 때
- 어떤 객체가 다른 객체에 자신의 변화를 통보할 수 있는데, 그 변화에 대해서 관심 있어 하는 객체들이 누구인지에 대한 가정 없이도 통보가 될 때
결과
- 감시자 패턴을 사용하게 되면 주체 및 감시자 모두를 독립적으로 변형하기 쉽다.
- 감시자를 재사용하지 않고도 주체를 재사용할 수 있고, 주체 없이도 감시자를 재사용 할 수 있다.
- 주체나 감시자의 수정 없이도 감시자를 추가할 수 있다.
1. Subject와 Observer 클래스 간에는 추상적인 결합도만이 존재한다.
2. 브로드 캐스트 방식의 교류를 가능하게 한다.
3. 예측하지 못한 정보를 갱신한다.
상태 ( State ) | Object for State
의도
- 객체의 내부 상태에 따라 스스로 행동을 변경할 수 있게 허가 하는 패턴
활용
* 이런 상황에서 사용 하면 좋다.
- 객체의 행동이 상태에 따라 달라질 수 있고, 객체의 상태에 따라서 런타임에 행동이 바뀌어야 하는 경우
- 어떤 연산에 그 객체의 상태에 따라 달라지는 다중 분기조건 처리가 너무 많이 들어 있을 때, 객체의 상태를 표현하기 위해
상태를 하나 이상의 나열형 상수로 정의 해야 한다. 동일한 조건 문장들을 하나 이상의 연산에 중복 정의해야 할 때도 많다.
이 경우 객체의 상태를 별도의 객체로 정의하면, 다른 객체들과 상관 없이 그 객체의 상태를 다양화 시킬 수 있다.
결과
1. 상태에 따른 행동을 국소화하며, 서로 다른 상태에 대한 행동을 별도의 객체로 관리한다.
* 새로운 상태와 새로운 전이 규칙이 발견되면, 새로운 서브 클래스만 정의 하면 된다.
상태가 많아질 경우 상태가 흩어지는 편이 실제로는 더 이득이다.
2. 상태 전이를 명확하게 만든다.
3. 상태 객체는 공유 될 수 있다.
* 상태는 단지 타입으로만 표현되므로, State 객체는 인스턴스 변수 없이 여러 Context 클래스의 인스턴스로도 객체를
공유 할 수 있다.
전략 ( Strategy ) | Policy
의도
- 동일 계열의 알고리즘군을 정의하고, 각 알고리즘을 캡슐화하며, 이들을 상호교환이 되도록 만든다.
알고리즘을 사용하는 클라이언트와 상관 없이 독립적으로 알고리즘을 다양하게 변경할 수 있게 한다.
활용
* 이런 상황에서 사용 하면 좋다.
- 전략 패턴은 많은 행동 중 하나를 가진 클래스를 구성할 수 있는 방법을 제공한다.
- 사용자가 몰라야 하는 데이터를 사용하는 알고리즘이 있을 때 노출하지 말아야 할 복잡한 자료구조는 Strategy 클래스에만 두면 되므로 사용자는 몰라도 된다.
- 하나의 클래스가 많은 행동을 정의하고, 그 클래스의 연산 안에서 복잡한 다중 조건문의 모습을 취하는 경우 많은 조건문보다는 각각을 Strategy 클래스로 옮겨 놓는 것이 좋다.
결과
1. 동일 계열의 관련 알고리즘군이 생긴다.
2. 서브클래싱을 사용하지 않는 대안이다.
3. 조건문을 없앨 수 있다.
4. 구현의 선택이 가능하다.
5. 사용자(프로그램)는 서로 다른 전략을 알아야 한다.
6. Strategy 객체와 Context 객체 사이에 의사소통 오버헤드가 있다.
7. 객체 수가 증가 한다.
관련
- 전략 객체는 규모가 작은 클래스들이므로 플라이급 패턴으로 정의하는 것이 좋다.
템플릿 메서드 ( Templete Method )
의도
- 객체의 연산에는 알고리즘의 뼈대만을 정의하고, 수행 할 구체적 처리는 서브 클래스로 미루는 방법.
알고리즘의 구조 자체는 그대로 놔둔 채 알고리즘 각 단계 처리를 서브 클래스에서 재정의 할 수 있게 하는 방식.
템플릿 메서드는 서브 클래스가 오버라이드할 수 있는 추상 연산을 사용하여 알고리즘을 정의한다.
활용
* 이런 상황에서 사용 하면 좋다.
- 어떤 한 알고리즘을 이루는 부분 중 변하지 않는 부분을 한 번 정의해 놓고 다양해질 수 있는 부분은 서브 클래스에서 정의하고자 할 때
- 서브클래스 사이의 공통적인 행동을 추출하여 하나의 공통 클래스에 몰아둠으로 코드 중복을 피하고 싶을 때
- 서브 클래스의 확장을 제어 할 수 있을 때
( 템플릿 메서드가 어떤 특정한 시점에 Hook 연산을 호출하도록 정의함으로 그 특정 시점에만 확장 할수 있게 만든다. )
* Hook 연산 : 필요하면 서브클래스에서 확장할 수 있는 기본 행동을 제공하는 연산/ 기본적으로는 아무 내용도 정의하지 않는다.
템플릿 메서드 패턴에서는 어떤 연산이 훅 연산(오버라이드가 가능한지?)인지? 추상 연산(반드시 오버라이딩 해야하는지)인지?
서브클래스는 부모 클래스에 정의된 연산을 명시적으로 호출하고 또 재정의함으로써 부모 클래스 연산의 행동을 확장함.
관련
* 팩토리 메서드 패턴은 종종 템플릿 메서드 패턴이라고도 한다.
템플릿 메서드 패턴은 상속을 이용하여 다양한 알고리즘을 만들어 낼 수 있다. 전략 패턴과 관계가 있으며, 각 전략들은 위임을 통하여
전체 알고리즘을 다양화 할 수 있다.
방문자 ( Visitor )
의도
- 객체 구조를 이루는 원소에 대해 수행할 연산을 표현하기 위해서 만들어짐.
연산을 적용할 원소의 클래스를 변경하지 않고도 새로운 연산을 정의할 수 있게 한다.
* 각 노드 클래스에서 서로 관련된 연산들을 추려 모아 별도로 하나의 객체로 묶는다!
이 묶음의 객체를 방문자라고 한다.
활용
* 이런 상황에서 사용 하면 좋다.
- 다른 인터페이스를 가진 클래스가 객체 구조에 포함되어 있으며, 구체 클래스에 따라 달라진 연산을 이들 클래스의 객체에 대해
수행하고자 할 때
- 각각 특징이 있고, 관련되지 않은 많은 연산이 한 객체 구조에 속해있는 객체들에 대해 수행될 필요가 있으며, 연산으로 클래스들을 지저분하고 싶지 않을 때
- 객체 구조를 정의한 클래스는 거의 변하지 않지만, 전체 구조에 걸쳐 새로운 연산을 추가 하고 싶을 때
* 객체 구조가 자주 변경 될 때는 해당 연산을 클래스에 정의하는 편이 더 유리하다.
결과
1. Visitor 클래스는 새로운 연산을 쉽게 추가 할 수 있다.
2. 방문자를 통해 관련된 연산들을 한 군데로 모으고, 관련되지 않은 연산을 떼어 낼 수 있다.
3. 새로운 ConcreteElement 클래스를 추가하기 어렵다.
4. 클래스 계층 구조에 걸쳐서 방문한다.
5. 상태를 누적할 수 있다.
6. 데이터 은닉을 깰 수 있다.
관련
- 복합체 패턴이 정의하는 복합 객체 구조에 대해 연산을 적용하는 데에 방문자를 쓸 수 있다.
- 방문자 패턴은 해석자 패턴의 해석 과정에도 사용 할 수 있다.
행동 패턴에 대한 논의
- Strategy 객체는 알고리즘을 캡슐화 한다.
- State 객체는 상태에 의존적인 행동을 캡슐화 한다.
- Mediator 객체는 객체 사이의 프로토콜을 캡슐화 한다.
- Iterator 객체는 집합 객체의 구성요소에 접근하거나 원소들을 순회하는 방법을 캡슐화 한다.
* 모든 패턴이 클래스 간의 정적 의사소통 방법을 정의 하는 것은 아니다.
책임 연쇄 패턴의 경우에는 의사소통에 관여하는 객체의 개수는 정해져 있지 않으며, 임의의 개수가 가능하다 .
다른 패턴의 경우 인자로 전달 되는 객체가 필요로 하다.
중재자 vs 감시자 패턴
둘의 차이는 감시자 패턴은 Observer 클래스와 Subject 클래스를 도입함으로써 객체 간의 상호 교류를 분산시킨 패턴이고,
중재자 패턴은 다른 객체 사이의 교류를 Mediator 객체 내에 캡슐화한 것이다.
즉, 하나의 주체에 대해서 여러개의 감시자를 둘 수도 있고, 어떤 주체의 감시자가 다른 감시자의 주체가 될 수도 있습니다. 즉, Mediator 클래스에 모든 처리 조건을 담당하도록 한 것.
감시자 패턴은 Observer 클래스와 Subject 클래스 사이의 결합도를 낮추기 때문에, 추후 재사용 할 수 있을 정도로 작은 단위로 만들어 지게 된다.
객체 간에 어떤 흐름이 있는지 파악하는 데는 중재자 패턴이 감시자 패턴보다 더 낫다.
감시자 패턴을 안다면, 감시자와 주체가 어떻게 연결 되는지 이해 하는 것은 중요하다.
명령 , 감시자, 중재자. 책임 연쇄 패턴은 메시지를 보내는 송신자와 메시지를 받는 수신자 사이의 결합도를 없애려는 패턴이다.
물론 각각 조금씩 다르긴 하다.
즉, Command 객체는 요청을 만들어 내는 간단한 인터페이스만 제공하며, 송신자-수신자의 연결을 분리함으로 송신자 객체는 다른 수신자 객체와도 일을 할 수 있게 되고, 결국 송신자 객체는 수신자 객체에서 분리되었기 때문에 송신자 객체의 재사용이 가능해지는 것이다.
감시자 패턴에서 정의한 Subject 와 Observer 인터페이스는 변화를 처리하기 위해서 설계한 것이며, 그러므로 객체 간에 자료 종속성이 있을 때는 객체 간의 결합도를 줄이는 데에 감시자 패턴이 가장 좋다.
Mediator 객체는 Colleague 객체 간에 요청이 처리되는 경로를 추상화하며, 함께 동작해야 하는 객체는 Mediator를 통해서만 다른 객체를 사용 할 수 있다.
중재자 패턴은 의사소통을 클래스 사이에 분산시키지 않고, 하나의 클래스에 집중시키기 때문에 시스템 내의 서브클래싱을 줄 일 수 있다. 책임 연쇄 패턴은 메시지를 받아 처리 할 수 있는 연결 고리를 따라서 계속 처리 요청을 보냄으로 메시지를 보낸 객체와 받는 객체 간의 종속성을 없앤다.
결론
템플릿 메서드 패턴은 기본 연산을 이용해서 어떤 객체가 요청을 처리 할 것인지 결정하거나 어떤 객체에게 메시지를 전달해야 하는지 결정한다.
책임 연쇄 패턴은 연결 고리를 따라서 요청이 여러 번 전달 되는 것이고, 템플릿 메서드 패턴은 서브 클래스로 한 번만 전달 된다.
연결 정보에서 전달 되는 요청을 객체로 표현하고 싶다면, 명령 패턴을 사용하면 된다. 해석자 패턴은 상태 패턴을 이용해서 파싱 상황을 정의 할 수 있고, 반복자 패턴은 집합 객체를 순회 할 수 있고, 방문자 패턴은 집합 객체에 속한 각 연산에 적용 할 수 있다.
행동 패턴은 또 다른 유형의 패턴과도 잘 통합 될 수 있다. 복합체 패턴을 사용하는 시스템이라면, 구성 객체의 요소에 연산을 수행하기 위해서 방문자 패턴을 사용할 수 있을 것이다. 각 요소들이 부모에 정의된 공통 특성을 알고 싶어 한다면, 책임 연쇄 패턴을 사용하는 것이 좋다.
한 객체를 다른 객체에 연결하고 싶으면 감시자 패턴을 사용하면 되고, 상태가 변할 때마다 행동을 변경시키고 싶으면, 상태 패턴을 사용하면 된다. 구성 자체는 빌더 패턴에서 사용한 방법으로 만들 수 있으며, 우너형 패턴처럼 사용 할 수 있다.
클래스 또는 객체 수준에서 하는 조합이 아닌 패턴 수준에서 하는 조합이 되어야 높은 활용성을 동반한 한결같은 시너지를 낼 수 있다.
|
'프로그래밍 > Design Pattern' 카테고리의 다른 글
| Design Pattern을 공부해보자 3탄 (0) | 2016.08.30 |
|---|---|
| Design Pattern을 공부해보자 2탄 (0) | 2016.08.30 |
| Design Pattern을 공부해보자 1탄 (0) | 2016.08.30 |
| GoF의 디자인 패턴 - 구조 패턴 (0) | 2015.10.13 |
| GoF의 디자인 패턴 - 생성 패턴 (0) | 2015.10.12 |