반응형
1. 정의.
의도
 - 객체 사이에 일 대 다의 의존 관계를 정의해 두어, 어떤 객체의 상태가 변할 때 그 객체에 의존성을 가진 다른 객체들이  그 변화를 통지받고 자동으로 갱신될 수 있게 만듭니다.
위키피디아
 - 옵서버 패턴(observer pattern)은 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 디자인 패턴이다. 주로 분산 이벤트 핸들링 시스템을 구현하는 데 사용된다. 발행/구독 모델로 알려져 있기도 하다.
해드퍼스트
 - 옵저버 패턴에서는 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one to many) 의존성을 정의합니다.

2. 동기
 - 클래스들 사이의 결합성을 낮추기위해(loosely coupled), 게시(publish)-구독(subscribe)과 같은 종류의 관계에 대해서 주체(subject) 와 감시자(observer) 의 형태로 나누어 객체의 상호작용을  표현하기 위함.

3. 활용성
 - 두 가지 형태를 갖는 객체의 상호작용 안에서 어떤 변경에 대해 통보를 받고 변경 되거나 이러한 변경에 대해 다른 객체들이 통보를 받아야 할 때.

4. 참여자
 - subject, observer, concreteSubject, concreteObserver

5. 협력방법
 - ConcreteSubject 는 Observer의 상태와 자신의 상태가 달라지는 변경이 발생할 때마다 감시자에게 통보합니다.
 - subject 의 notify 동작을 통해 등록된 observer 들의 상태를 갱신하도록 합니다.

6. 결과
 - Observer 패턴을 사용하게 되면 주체 및 감시자 모두를 독립적으로 변형하기 쉽습니다.
—Subject 와 Observer 클래스 간에는 추상적인 결합도만이 존재합니다.
— 브로드캐스트 방식의 교류를 가능하게 합니다.
— 예측하지 못한 정보를 갱신합니다.

7. 구현 (고려해야 될 부분)
- Subject 와 그것의 Observer들을 대응시킵니다.
- 하나 이상의 Subject를 감시합니다.
- 누가 Notify 를 촉발시킬 것인가.
- 삭제한 Subject에 대한 Dangling Reference 를 계속 유지할 때가 있습니다.
- 통보 전에 주체의 상태가 자체 일관성을 갖추도록 만들어져야 합니다.
- Observer 별 갱신 프로토콜을 피합니다.(Push Model / Pull Model)
- 자신이 관심있는 변경이 무엇인지 명확하게 지정합니다.
- 복잡한 갱신의 의미 구조를 캡슐화 합니다.
- Subject 와 Observer 클래스를 합칩니다.

8. Diagram




반응형
반응형
1. 정의. 
의도
 - 객체의 내부 상태에 따라 스스로 행동을 변경할 수 있게 허가하는 패턴으로, 이렇게 하면 객체는 마치 자신의 클래스를 바꾸는 것처럼 보입니다.
위키피디아
The state pattern, which closely resembles Strategy Pattern, is a behavioral software design pattern, also known as the objects for states pattern. This pattern is used in computer programming to encapsulate varying behavior for the same object based on its internal state. This can be a cleaner way for an object to change its behavior at runtime without resorting to large monolithic conditional statements[1]:395 and thus improve maintainability.[2] 
해드퍼스트
 - 스테이트 패턴을 이용하면 객체의 내부 상태가 바뀜에 따라서 객체의 행동을 바꿀 수 있습니다. 마치 객체의 클래스가 바뀌는 것과 같은 결과를 얻을 수 있습니다.

2. 동기.
- 한 시스템(책에서는 TCPConnection)의 모든 상태를 표현하는 추상클래스를 통해 각 상태별로 어떻게 동작하는지 관리할 수 있다.
- 상태 조건들이 복잡한 분기문에 숨어 있는 경우 유지보수와 확장에 어려움이 있다.

3. 활용성.
 - 객체의 행동이 상태에 따라 달라지며, 런타임 시에 행동이 바뀌어야 할 때와 다중 분기 조건 처리가 너무 많을 때.

4. 참여자.
 - Context, State, ContcreteState

5. 협력방법.
-  Context 에 있는 State 의 기본 인터페이스를 통해서 Context 클래스에서 현재 상태를 정의하고, 상태에 따라 다른 요청을 받으면 ConcreteState 객체로 전달합니다. 이러한 Context 를 통해 사용자는 State 객체를 직접 다루지 않고 요청을 보내기만 하면 됩니다.

6.결과.
 - 상태에 따른 행동을 국소화하며, 서로 다른 상태에 대한 행동을 별도의 객체로 관리합니다.
 - 상태 전이를 명확하게 만듭니다.
 - 상태 객체는 공유 될 수 있습니다.
 - 동적 상속을 이용하는 방법.

7. 구현(고려해야 될 부분)
 - 누가 상태 전이를 정할 것인가? (Context? State?)
 - 테이블 기반의 대안(다음 상태에 대한 전이 저장) -> Table Driven State  Pattern
 - 상태 객체의 생성과 소멸.

8. Diagram.







반응형
반응형
Decorator Pattern


디자인 카탈로그에는 ...
 - 주어진 상황 및 용도에 따라 어떤 객체에 책임을 덧붙이는 패턴으로, 기능 확장이 필요할 때 서브클래싱 대신 쓸 수 있는 유연한 대안이 될 수 있습니다.
디자인 패턴 영역 - 구조 및 객체 패턴.
디자인 패턴 관계도 - (composite -> adding responsibilities to objects)

의도 - 객체에 동적으로 새로운 책임을 추가할 수 있게 합니다. 기능을 추가하려면, 서브클래스를 생성하는 것보다 융통성 있는  방법을 제공합니다.
* 데코레이터 패턴에서는 객체에 추가적인 요건을 동적으로 첨가한다.
데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방법을 제공한다.(상속을 이용해 타입을 맞춘다.)

동기 - 정적인 상속이 아니라 동적인 상황에서 필요할 때-! 객체에 책임을 부여(추가/삭제)하고 싶을 때 사용합니다. 

활용
1. 동적으로 또한 투명하게 다른 객체에 영향을 주지 않고 개개의 객체에 새로운 책임을 추가하기 위해 사용합니다.
2. 제거될 수 있는 책임에 대해 사용합니다.
3. 상속으로 서브클래스를 생성하는 방법이 실질적이지 못할 때 사용합니다.

결과
이익1. 단순한 상속보다 설계의 융통성을 더 많이 증대시킬 수 있습니다.
이익2. 클래스 계통의 상부측 클래스에 많은 기능이 누적되는 상황을 피할 수 있습니다.
부담1. 장식자와 해당 그 장식자의 구성요소가 동일한 것은 아닙니다.
부담2. 장식자를 사용함으로써 작은 규모의 객체들이 많이 생깁니다. 이 때 객체들을 잘 이해하지 못하고 있다면 시스템을 수정하는 과정이 복잡해 진다.

* OCP 를 만족시키는 패턴. 클래스는 확장에 대해서는 열려 있지만 변경에 대해서는 닫혀 있어야 한다.





반응형
반응형
Bridge Pattern

디자인 패턴 카탈로그에는...
 - 구현부의 추상층을 분리하여 각자 독립적으로 변형할 수 있게 하는 패턴입니다.
디자인 패턴 영역 - 구조 및 객체 패턴.
디자인 패턴 관계도 - X.

의도 - 구현에서 추상을 분리하여, 이들을 독립적으로 다양성을 가질 수 있도록 합니다.
* 구현 뿐만 아니라 추상화된 부분까지 변경시켜야 하는 경우에 사용한다.

동기 - 상속대신 추상클래스를 사용하더라도, 추상적 개념을 구현과 분리해서 재사용,수정,확장하기 어려움이 있다. 추상적 개념을 구체적인 구현에 종속적일 필요 없이 생성할 수 있게 해야 한다. (책의 윈도우 컨셉?과 플랫폼이라 표현하고 싶다.)

활용 - 클라이언트가 구현을 모르더라도 구현에 대해 여러 가지 형태를 추상적으로 사용가능하게 한다.
1. 추상적 개념과 이에 대한 구현 사이의 지속적 종속관계를 피하고 싶을 때.
2. 추상적 개념과 구현 모두가 독립적으로 서브클래싱을 통해 확장되어야 할 때.
3. 추상적 개념에 대한 구현 내용을 변경하는 것이 다른 관련 프로그램에 아무런 영향을 주지 않아야 할 때.
4. 사용자들은 사용자에게 구현을 완벽하게 은닉하길 원할 때 (private 을 사용하여).
5. 클래스 상속 계통에서 하나의 이유로 여러 개 클래스가 갑자기 정의되어야 하는 상황일 때.
6. 여러 객체들에 걸쳐구현을 공유하고자 하며, 또 이런 사실을 사용자 쪽에 공개하고 싶지 않을 때.

결과
1.인터페이스와 구현 분리.
2. 확장성 제고. (Abstraction과 Implementor 각자).
3. 구현 세부 사항을 사용자에게서 숨기기.





반응형

+ Recent posts