Motivation
OOP를 이야기 할때 객체의 상태를 빼놓고 얘기 할 수 없습니다. 결국 OOP라는 것은 객체와 객체의 상호작용에 대한 것입니다.
객체가 다른 객체로 부터 상태정보를 자주 전달받아야하는 상황에 그 객체들간의 결합도와 의존성을 최대한 나출수 있는 방법으로 옵저버 패턴을 사용해 봅시다!
stocks server ( subject ) 를 통해 웹 브라우저, 모바일 앱 등 다양한 client ( observer )에게 알림을 주어야 하는 상황을 생각해봅시다.
Intent
- 객체간에 1대 N 관계가 있을때 1의 변화에 따라 N의 객체들이 변경을 알림받고 상태를 자동으로 업데이트 한다.
- Observable - 발행
- ConcreteObservable - Observable의 구체 클래스
- Observer - 구독
- ConcreteObservable - Observer의 구체 클래스
Applicablity
이럴때 옵저버 패턴을 쓰자!
- 높은 결합도 없이 한 객체의 상태 변화를 다른 객체에 반영시키고 싶을때
- 미래에 새로운 옵저버 (클라이언트)를 추가할 것으로 예상될때
Examples
Some Classical Examples :
- MVC 패턴 (View 가 Observer이고 Model 이 Observeable임)
- Event Management - Java Swing, dot Net 에서는 Event Management에 Observer 패턴을 광범위하게 활용함
뉴스 에이전시
Specific problems
N : M 발행 구독 관계
Publish 가 notify를 호출할때 자신의 참조를 걸면 된다.
누가 실질적으로 상태의 update를 하는가?
상태의 전이는 publish 객체의 notify를 호출하는 것으로 부터 시작된다.
근데 변경이 자주 일어나지 않는다면? Subscriber가 publisher의 상태를 계속해서 확인하는 것이 불필요하고 성능상 저하를 일으킨다.
Subscriber가 직접 notify를 호출하는 것이 효출적이다 (???)