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만 추가하면 됨.