Head First Design Patterns : (2)옵저버 패턴

옵저버 패턴(Observer Pattern)

한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 연락이 가고, 자동으로 내용이 갱신되는 방식

일대다 의존성을 정의

 

• Subject와 Observer 인터페이스를 각각 구현 - WeatherData(Subject), Displays(Observer)
• Subject엔 옵저버 등록, 삭제, 알림 메소드 필요
• 옵저버는 update() 메소드 구현. - update(온,습,압)

+ 옵저버한테 연락이 가는 순서에 의존해서 코딩하면 안 됨.

 

자바 내장 옵저버 패턴

- 푸시 방식뿐만 아니라 풀 방식으로 갱신 가능

- Subject가 아니라 Observable 클래스 상속받아 사용 - WeatherData(extends Observable)

- 옵저버 객체에선 위 클래스의 addObserver() 호출해서 사용

 

*Observable에서 연락을 돌리는 방법

- setChanged() 메소드로 상태 변화를 알림

- notifyObserver() / notifyObserver(Object arg) 메소드 호출

• setChanged() 선호출 안 하면 notifyObserver()는 동작하지 않음
• 이유? 값이 자주 바뀌는 경우 알림을 최적화하기 위해
• 특정 조건에 맞는 변경 상태 때만 알림을 보내고 싶을 때 setChanged를 수정하면 됨.

*옵저버가 연락을 받는 법

- update() 메소드를 구현하지만 서명이 조금 다름

- update(Observable o, Object arg) - 주제 객체와 notifyObserver에서 인자로 전달된 객체가 전달됨.

 

*pull 방법

- notifyObserver()로 아무런 객체를 보내지 않고

- 옵저버 객체 update() 메서드에서 주제 객체를 통해 직접 get 함

 

+Observable의 단점 :

• 클래스기 때문에 서브클래스를 만들어야 함. 중복 상속이 안되기 때문에 재사용성에 재약
• Observable인터페이스라는 게 없어 자바 내장 Observer API와 잘 맞는 클래스 구현이 불가능함.

 

---

디자인 원칙 

+ 서로 상호작용을 하는 객체 사이에서는 가능하면 느슨한 결합 디자인을 사용해야 한다.

 

- 바뀌는 부분 분리 : 옵저버 패턴에서 변하는 것은 주제의 상태와 옵저버의 개수, 형식. 주제를 바꾸지 않고도 주제의 상태에 의존하는 객체들(옵저버)을 변경 가능.

- 인터페이스에 맞춰 프로그래밍 : Subject/Observer 인터페이스를 구현

- 상속보단 구성 : 주제와 옵저버 사이 관계는 상속이 아니라 실행 중에 구성되는 방식

 

 

연필을 깎으며

page 80

- A B C E 

 

 

NOTE

- push 방식과 pull 방식

• push : 주제 객체에 대한 정보를 직접 접근 x,
• pull : 원하는 객체만 원하는 값에 접근 가능, 주제 객체가 확장될 때 그냥 getter만 추가하면 됨.