옵저버 패턴

---

옵저버 패턴(observer pattern)은 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 디자인 패턴이다.

옵저버 패턴이 필요한 이유 ?

Customer과 Store객체가 있다고 가정했을때, Customer가 사고자하는 인기있는 상품이 있다. 이 상품을 사기 위해서 출시되는지 매일 확인하러 오게되면 시간낭비를 할 것이다.

이때, Store에서 특정 상품이 재입고 되는 것을 알려주게 된다며느 고객의 시간을 절약해 줄 수 있을 것이다.(그러나 이 상품을 원하지 않는 고객들에게도 문자가 가면 사고싶지 않은 고객들은 불편함을 느낄 것이다.)

이때 발생 할 수 있는 문제들이 있다.

1. 스토어에서 메일을 보내주지 않을 경우 → 고객의 시간 낭비
2. 스토어에서 메일을 보내는 경우 → 관심이 없는 고객에게도 메일 보낼 가능성 있다.

해결책

두 종류의 객체가 있다고 생각해보자

• Publisher - 다른 객체에게 상태 변화를 알려줄 객체
• Subscibers - Publisher의 상태 변화를 추적하기 원하는 객체 (=Observer)

  Observer 패턴은 구독 매커니즘을 사용한다.

Publisher

1. Publisher는 구독자 정보를 갖고있다.

2. 구독자로 등록한다.

: 내가 만약 Publisher에(ex. 제품의 출시) 상태를 추적하고 싶은 경우 Subscriber로 등록 한다. 실제 앱의 경우 아마 수십개의 다른 subscriber class가 존재할 것이다.

3. 구독자들에게 변화를 알린다.

: Publisher의 상태의 변화가 있는 경우 등록된 Subscribers에게 변화를 알려주게 된다. Publiser는 반드시 알림(notification) method를 선언해야 한다. 알림 메소드는 일부 데이터를 파라미터로 전달할 수 있어야 한다.

4. 언제든지 구독을 취소 할 수 있다.

Subscriber

1. 모든 subscriber들은 동일한 인터페이스를 구현하고 있어야 한다.

전체 과정

Publisher와 Subscriber를 각각 살펴 보았다면 이제 전체 과정을 정리해보자.

1. publisher는 subsciptions 데이터를를 가지고 있어서 구독자를 리스트에 추가하거나 제거할 수 있다.

2. Publisher의 상태가 변하거나 행동(behavior)을 할 때, 이벤트가 발생한다. 새로운 이벤트가 발생 했을 때, publisher는 각각의 구독자 객체에 인터페이스에 선언된 notification method를 호출한다.

3. Subscriber 인터페이스는 notification 인터페이스를 선언한다. 대부분의 경우에 하나의 update 메소드로 구성되어있다. 이 메소드는 여러개의 파라미터(publisher가 보낸 event와 관련된 것들)를 가질 수 있다.

4. 구체적인 subscriber는 publisher에 의한 notification에 대한 응답으로 몇가지 action을 수행한다. 모든 클래스는 반드시 같은 인터페이스를 구현하고 있어서 publisher가 구체적인 클래스를 복제 하지 않는다.

5. 보통, subscriber는 update를 올바르게 처리하기 위한 정보들이 필요하다. 이러한 이유로, Publisher는 관련 데이터를 notification method의 인자로 보낸다.

6. client는 pulisher과 subscriber객체를 생성하고, 등록한다.

옵저버 패턴 장단점

---

장점

• Open/Close원칙
• 런타임 시간에 객체 간의 관계를 설립할 수 있다.

단점

• 구독자들은 랜덤한 순서로 notify를 받게 된다.

Reference & Additional Resources

• https://velog.io/@ellyheetov/Observer-Pattern