옵저버 패턴 Observer Pattern

@참고 사이트

-http://hyeonstorage.tistory.com/165

-http://blog.lifeis.gift/175

@옵저버 패턴 예제 

1. 자동차를 탈 때

-연료가 소진될 때까지의 주행가능거리를 출력하는 클래스

-연료량이 부족하면 경고 메세지를 보내는 클래스

-연료량이 부족하면 자동으로 근처 주유소를 표시하는 클래스

-->이 세 클래스는 차량의 연료량의 변화를 알아야 한다.(통보받아야 한다)

이 때 옵저버 패턴을 이용해서 Subject Class(연료량 데이터를 가진 클래스)가 연료량이 변화할 때마다 세 클래스에 연료량을 통보해주면 된다.

-세 클래스가 Observer가 된다. Observer끼리는 같은 형태의 클래스일 필요가 없다. Observer의 인터페이스만 구현되어 있으면 된다.

2. 센서값 출력할 때

-다양한 센서에서 들어오는 데이터를 여러 출력기기에 출력할 때를 생각해보자.

-아래와 같은 구조를 가질 때 옵저버 패턴을 사용하면 좋을 것 같다.

3. 게임에서 파티가 함께 몬스터를 잡을 때

-몬스터가 Subject가 되고, 파티원들은 몬스터의 상태변화를 모두 알고 있어야 한다.

-마법사가 몬스터를 공격해서 몬스터의 상태가 변화되면, 이 변화를 사냥꾼, 전사, 사제 등의 파티원들이 모두 알아야 한다.

-이런 상황에서 옵저버 패턴이 유용할 것이다.

4.

참고 사이트-https://www.sitepoint.com/understanding-the-observer-pattern/

-Ignatius Teo라는 사람의 경험.

-최근에 제 3 자 포럼 소프트웨어를 기존 웹 포털에 통합하라는 요청을 받았습니다. 문제는 두 응용 프로그램 모두 자체적 인 별도의 인증 메커니즘이 있다는 것입니다. 사용자 관점에서 포럼에 별도로 로그인 할 필요없이 사용자가 포털에 로그인하는 것이 이상적입니다. 그리고이 경우 관리 코드가 불필요하게 수정되기를 원하지 않았습니다. 이후의 업데이트와 버그 수정을 벤더에서 병합하고 수정 사항을 덮어 쓰지 않도록주의해야합니다. 이것은 옵서버 패턴이 나에게 유용했던 곳이다.

--> 요약 : 포럼 소프트웨어를 기존 웹 포털에 통합해야 했다. 이 때 둘다 별도의 인증메커니즘이 있었다. 하지만 사용자 입장에서는 웹 포털에 로그인했을 때 포럼에도 함께 로그인되는 것이 편하다. 개발자 입장에서는 관리코드가 불필요하게 수정되지 않기를 원했다. 이런 상황에서 옵저버 패턴이 유용했다.

@옵저버 패턴의 특징

-인터페이스를 사용하여 느슨한 결합/낮은 의존성을 추구하는 것이 좋다.

-데이터가 변경되었을 때 상대 클래스나 객체에 의존하지 않으면서 데이터 변경을 통보하고자 할 때 유용하다.

-Push방식과 Pull방식이 있다.