2장 : 옵저버(Observer) 패턴 -2-

@ 푸시방식과 풀방식 : 주제(subject)에서 데이터를 구독자들(observer)에게 보내는 방식(푸시방식)과 옵저버가 데이터를 가져가는 방식(풀방식)이 있다.(자바에 내장된 옵저버 패턴이 제공됨)

@ subject는 Observable클래스를 확장하고 구독자들은 Observer 인터페이스를 구현한다.

@ Observable 객체
- addObserver() : 옵저버 등록
- deleteObserver() : 목록에서 탈퇴
- setChanged() 메서드에서 changed플래그 값을 참으로 설정한다. notifyObserver()에서는 changed 플래그가 참일 경우 모든 목록에 있는 옵저버 인터페이스를 구현한 구독자들의 update()메서드를 실행하고 이때 연락을 보내는 주제 객체와 데이터 객체를 인자로 넘긴다. 연락이 끝나면 changed플래그를 false로 설정한다.
- setChanged() 메서드는 연락을 최적화할 수 있게 해 줌으로써 옵저버들을 갱신하는 방법에 있어서 더 광범위한 유연성을 제공한다.
- clearChanged()메서드는 changed플래그를 false로 설정해준다.
- notifyObserver()를 호출할 때 데이터 객체를 보내지않는 것은 풀방식임을 의미

@ Observable 객체의 단점
1. 클래스기 때문에 서브 클래스를 만들어야한다. 만약 대상 클래스가 이미 다른 객체를 확장하고 있다면 이중으로상속할 수 없으며 재사용성에 제약이 생길 수 있다.
2. setChanged() 메서드가 protected로 선언되어 있어서 서브 클래스에서만 setChanged()를 호출할 수 있다. 이는 상속보다는 구성을 사용한다는 디자인 원칙에 위배된다.

@ JButton과 ActionListener는 옵저버 패턴을 이용한 좋은 예이다. JavaBeans나 RMI에도 광범위하게 쓰인다.

@ Observable에서는 옵저버들이 Observer 인터페이스를 구현한다는 것을 제외하면 옵저버에 대해 전혀 모르기 때문에 이들사이에 결합은 느슨한 결합이다.

@ 옵저버들한테 연락을 돌리는 순서에 절대로 의존하면 안된다.

2장 예제 :

design2.jar