[Design Pattern] 옵저버 패턴(Observer Pattern)에 대해 알아보자

Definition

Observer Pattern은 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에게 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one-to-many) 의존성을 정의한다.

- Behavioral Pattern

 

Situation

- 다른 객체의 상태가 변경될 때마다 어떤 이벤트를 실행하고 싶을 때

- 한 객체의 상태가 변경되면 다른 객체도 변경해야 할 수 있고 실제 객체 집합을 미리 알 수 없거나 동적으로 변경되는 경우

- 앱의 일부 객체가 다른 객체를 제한된 시간 동안 또는 특정 경우 관찰해야 할 때

- 통신에는 느슨한 결합이 필요함

- 하나 이상의 객체의 상태 변경은 다른 객체의 동작을 트리거해야 함

- 방송 기능이 필요할 때

- MVC 패턴에서 사용됨 [ViewController -> Observer(Subscriber) & Model -> Subject(Publisher) ] 

 

 

Structure

https://refactoring.guru/design-patterns/observer

 

Pros

- OCP를 지킬 수 있음

- 게시자의 코드를 변경하지 않고도 새 구독자 클래스를 도입할 수 있음

- 느슨한 결합 때문에 변경 사항이 생겨도 쉽게 처리할 수 있는 유연한 객체지향 시스템 구축 가능

 

Cons

- 구독자는 무작위 순서로 알림을 받음

 

비슷한 패턴

Chain of Reponsibility, Command, Mediator와 Observer는 요청의 발신자와 수신자를 연결하는 다양한 방법을 다룬다.

• Chain of Responsibility는 잠재적 수신자 중 하나가 처리할 때까지 잠재적 수신자의 동적 사슬을 따라 순차적으로 요청을 전달한다.
• Command는 발신자와 수신자간의 단방향 연결을 설정한다.
• Mediator는 송신자와 수신자 간의 직접 연결을 제거하여 중재자 객체를 통해 간접적으로 통신하도록 한다.
• Observer를 사용하면 수신자가 수신 요청을 동적으로 구독 및 구독 취소할 수 있다

---

Observer 패턴은 1개의 Publisher에 대해 N개의 Subscriber가 존재하지만 Mediator는 M개의 Publisher와 N개의 Subscriber가 존재한다. M개의 Publisher가 서로서로 상태를 관찰하기 때문에 Publisher가 Subscriber가 되거나, Subscriber가 Publisher가 될 수 있다.

---

Mediator와 Observer의 차이는 파악하기가 어렵다. 대부분의 경우 이러한 패턴 중 하나를 구현할 수 있다. 그러나 때로는 두 가지를 동시에 적용할 수도 있다.

 

Mediator의 주요 목표는 시스템 구성 요소 집합 간의 상호 종속성을 제거하는 것이다. 대신 이러한 구성 요소는 단일 중재자 객체에 종속된다. 

Observer의 목표는 일부 객체가 다른 객체의 종속 역할을 하는 객체 간에 동적 단방향 연결을 설정하는 것이다.

 

Observer에 의존하는 Mediator 패턴의 대중적인 구현이 있다. Mediator 객체는 게시자의 역할을 하고 구성 요소는 Mediator의 이벤트를 구독 및 구독 취소하는 구독자 역할을 한다. 이러한 방식으로 Mediator를 구현하면 Observer와 매우 유사해 보일 수 있다.

 

혼란스러우면 다른 방법으로 Mediator 패턴을 구현할 수 있음을 기억하라. 예를 들어 모든 구성 요소를 동일한 중재자 객체에 영구적으로 연결할 수 있다. 이 구현은 Observer와 유사하지 않지만 여전히 Mediator 패턴의 인스턴스이다.

 

이제 모든 구성 요소가 게시자가 되어 서로 간의 동적 연결을 허용하는 프로그램을 상상해 보자. 중앙화 된 Mediator 객체는 없고 분산된 Observer 집합만 있을 것이다.