[디자인패턴] 옵서버(Observer ) 패턴이란? 또는 Event-Listener

Observer 패턴은 Behavioral Design Pattern이다.

개인적으로는 Observer 패턴보다 event-listener라는 이름이 더 직관적이라고 생각한다. 하지만 범용적인 용어를 사용하겠다.

 

휴대폰 가게 A와 손님이 있다고 가정해보자. 손님은 새로운 아이폰이 갖고 싶어 매일같이 가게에 방문에 아이폰이 출시되었는가 확인한다. 새로운 기기가 한 달 뒤에 나올지 일년 뒤에 나올지는 아무도 알 수 없다. 손님의 무의미한 방문은 계속된다.

휴대폰 가게 B에서는 다른 방식을 택한다. 새로운 휴대폰이 나올 때마다 가게 인근에 사는 모든 사람들에게 이메일을 전송해 휴대폰이 출시되었음을 알린다. 일부 사람에게는 희소식이 될 수 있지만 이 소식에 관심없는 사람에게는 스팸 메일에 불과하다.

가게와 고객은 서로를 끊임없이 확인해야 한다. 결합도가 매우 높은 상태다.

문제점

1. 휴대폰 가게 A를 이용하는 손님은 신제품 소식을 위해 시간을 낭비한다.
2. 휴대폰 가게 B를 이용하는 손님은 원치 않는 스팸을 듣고, 휴대폰 가게 B는 소식을 원치 않는 수많은 사람에게 메일을 보내는 자원 낭비를 한다.
3. 모듈간 결합도가 매우 높아 코드 수정, 추가 등 변경사항이 있을 경우 기존 코드를 수정해야 한다. OCP에 위반된다... 

SOLID 원칙을 준수하기 위해 반드시 신경써야 하는 것 중 하나는 모듈간 결합도를 낮추는 일이다.

 

 

만약, 가게에서 신제품 소식을 원하는 사람에게만 메일을 보낸다면 어떨까? 손님은 자신이 가게까지 찾아가지 않아도 되니 좋고 가게는 소식을 원하는 손님에게만 메일을 보낼 수 있으니 서로 좋은 일이다!

✅ 이렇게 데이터의 변경이 발생했을 때 상대 객체에 의존하지 않으면서 데이터 변경을 통보하고자 할 때 유용하다.

 

상태가 변할 수 있는 객체를 우리는 Subject라 한다. 예시 속 가게가 Subject이나 우리의 Subject는 손님에게 메시지를 전달하는 Publisher 역할도 맡는다. 손님은 ConcreteObserver가 되어 데이터 변경을 통보받게 된다.

 

일반화된 Observer 패턴 클래스 다이어그램

예시 상황을 적용해본 Observer 클래스 다이어그램. Store, Customer의 이름 말고는 위와 같다

 

당연히 ConcreteObserver는 여럿으로 추가될 수 있다. 손님 뿐만 아니라 신문에서 새로운 아이폰 소식을 듣고자 한다면 News 클래스를 추가하고 Observer를 implements하면 된다. Store의 새로운 구독자로 attach해주는 작업을 마친다. 이제 가게에서 새로운 아이폰 소식을 발행하면 구독자인 손님과 신문은 해당 소식을 듣게 된다. 소식을 원치 않는 학교, 식당에서는 불필요한 소식에서 해방된다!

참고로 우리가 어플리케이션으로 개발하는 대부분의 상품은 ConcreteObserver에 해당한다.

 

 

우리가 맨 처음 살펴본 다이어그램은 모든 관계에서 양방향 관계를 이룬다. 마지막으로 본 다이어그램은 모든 클래스가 단방향 관계를 이룬다. 서로 관계를 이루는 대상이 모두 다르다! ➡️ 결합도가 낮아졌다.

 

 

 

 

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

옵서버 패턴