2장 Observer Pattern
엠파스 블러그에서 가져옵니다.
너무도 많이 들어본 이름.. 옵져버 스타크래프트의 럴커나 다템 같은 안보이것 까지 볼 수 있는 유닛이다.
게임 중 후반에 이르러 옵져버가 있으면 상대방이 어디에 무슨 병력을 얼만큼 갖다 놨는지 무슨 건물을 짓고 있는지 훤히 알 수 있기 때문에 매우 중요한 유닛이다.
사설은 이만 하고 본론으로 들어갑니다.
책의 첫 부분에 기상 모니터링 애플리케이션 개요가 나오고 있습니다.
여기서 우리가 구현해야 할 부분은 WeatherData객체가 데이터를 취득하는 부분과 디스플레이 장비에서 기상 상태를 화면에 표시하는 부분입니다.
그렇다면 기본적으로 WeatherData class에는 기상 스테이션으로 부터 습도, 온도, 압력 data를 가져오는 메소드들을 구현해야 할 것입니다. 그리고 매번 상태가 바뀔때마다 현재 객체가 가지고 있는 습도, 온도, 압력 값을 바꿔 주어야 하며 디스플레이 장비에도 새로운 정보를 바탕으로 표시 해주어야겠지요..
따라서 다음과 같은 class diagram을 그릴 수 있습니다.
이 class의 일부를 구현하면 다음과 같이 됩니다.
public class WeatherData {
public void measurementsChanged() {
float temp = getTemperature();
float humidity = getHumidity();
float pressure = getPressure ();
currentConditionDisplay.update( temp, humdity, pressure );
statisticsDisplay.update( temp, humdity, pressure );
forecastDisplay.update( temp, humdity, pressure );
}
}
이 코드를 보면 display하는 class들과 다음과 같은 관계가 있다는 것을 알 수 있습니다.
이 때 문제는 measurementsChanged()에서 특정 구현된 class들에 의존한다는 것입니다.
1장에서 보았던 구현이 아닌 인터페이스를 사용하라던 원칙에 위배됩니다.
그나마 다행인 것은 Display interface를 사용하여 method이름은 update()라는 공통의 이름을 사용한다는 것인데.. 어차피 특정 구현에 의존한다면 별로 장점이 없다고 생각합니다.
그리고 만약에 새로운 Display형태가 추가되면 measurementsChanged의 코드 역시 바껴야 한다는 것입니다.
이러한 문제점을 보안하려면 어떻게 해야할까요 먼저 옵져버 패턴을 공부한 뒤에 해결하도록 합시다.
투비 컨티뉴드
여기서 하나 의문점...
WeatherData 객체가 있고 이를 구독하는 Display들이 있습니다. 그리고 WwatherData의 정보를 바꾸는 무언가가 있습니다. 여기서는 이 무언가가 기상스테이션이죠.
그런데 WeatherData 클래스를 보시면 getter들이 셋이 있는데 이 getter들은 자신의 정보를 다른 클래스에 넘겨주는 accessor 역할을 하는 것이 아니라 기상스테이션에서 정보를 가져오는 역할을 하고 있습니다. 이부분은 뭔가 잘못된 것이 아닌가.. 생각해봅니다.