Observer Pattern

@Desc
 : Observer pattern은 상태가 변할 때마다 객체들에게 새 소식을 알려주는 기법이다.
 : 객체 쪽에서는 계속해서 정보를 받을지 여부를 실행 중에 결정할 수 있다.
 : "한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 연락이 가고,
    자동으로 내용이 갱신되는 방식으로 one-to-many 의존성을 정의하는 구현 방식이다."

@Example
1) Weather Monotoring Application을 구현해 보고자 한다. 
2) 이 시스템의 한 쪽에는 실제 기상 정보를 수집하는 Weather Station이 있고,
3) 다른 쪽에는 그 데이터를 수집하는 WeatherData 객체와 사용자정보를 보여주는 Display 장비가 있다.
4) 이때 Weather Station 기상 정보는 WeatherData 객체로 가져올 수 있다고 가정하자. 그러면 우리는,
5) WeatherData 객체를 사용하여 사용자에게 필요한 정보만 보여주면 된다.

6) 가장 쉬운 구현은 measurementChanged 시점에 각 Display 객체가 직접 update를 하는 방법이다.
7) 즉, WeatherData 클래스의 measurementChanged() 호출 시 xxDisplay.update() 를 수행하는 것이다.
8) 이 방식은 WeatherData 클래스가 Concrete Display 객체를 처음부터 포함하고 있어야 하며,
9) 나중에 필요가 없어져도 제거할 수 없음을 뜻한다. 
10) Display 객체가 원할 때 상태 정보를 받고, 또 원할 때 안 받을 순 없을까? 

10) 신문이나 잡지를 구독하는 방법을 생각해보자.
11) 신문사가 사업을 시작하고 매일 신문을 찍어낸다.
12) 고객이 신문사에 신문 구독을 신청하면 매일 나오는 신문을 받아볼 수 있다.
13) 신문을 더 이상 보고 싶지 않으면 구독을 해지하면 되고 그러면 더 이상 신문이 오지 않는다.
14) 신문사가 영업을 계속 하는 동안에는 누구나 원할 때 구독/해지를 할 수 있다.
15) 이 방법은 문제 해결의 좋은 방법처럼 보인다.

16) Observer Pattern에서는 Subject(신문사)와 Observer(고객)가 있다.
17) Subject는 Observer를 등록(Register)하거나, 제거(Remove)하거나, 상태변화를 공지(Notify)한다.
18) Observer는 Subject로부터 받은 정보를 갱신(Update)하고 처리한다.
19) Subject는 Observer를 잘 몰라도 된다. Observer의 공통 부분만 Interface로 제공하면,
20) Observer들 각각의 구체적인 구현과 관계없이 Subject와 Observer는 독립적으로 분리될 수 있다.
21) 이렇게 Interface로 두 객체를 느슨하게 결합하면 Observer를 원할 때 등록/제거가 가능해진다.
22) 예를 들면, Subject는 Observer Interface의 List만 가지고 있으면 되고, 
23) List 내 모든 Observer에게 상태가 변할 때마다 Notify만 해주면 된다.

@Caution
24) Notify하는 방식에는 Push Model과 Pull Model이 있다.
25) Push Model은 Subject에서 상태 정보 전체를 Observer에게 뿌리는 방식이고,
26) Pull Model은 Subject와 의존성은 생기지만 Observer가 원하는 정보만 받아갈 수 있는 방식이다.
27) Observer Pattern 구현 시에는 Observer들에게 연락을 돌리는 순서에 절대로 의존하면 안 된다.

@Principle
  " Loose Coupling " (느슨한 결합)
  : 두 객체가 느슨하게 결합되어 있다는 것은, 
    그 둘이 상호작용을 하긴 하지만 서로에 대해 잘 모른다는 것을 의미한다.