19. 옵저버 패턴 (observer pattern)

옵저버 패턴

다수의 객체가 특정 객체 상태 변화를 감지하고 알림을 받는 패턴

--> 발행(publish)-구독(subscribe) 패턴을 구현할 수 있다.

Subject : 여러 옵저버들의 기능을 등록하거나 해지하는 것이 Subject의 주요 목적, Subject의 상태가 변경이 되면 자신의 옵저버들을 순회하면서 옵저버가 제공하는 특정 메소드들을 호출한다.

Observer : 공통된 인터페이스를 제공해서 어떤 이벤트가 발생했을 때, 인터페이스 안에서 옵저버가 해야할 일을 수행한다.

ConcreteObserver: Observer인터페이스의 구현체

---

코드로 알아보기

 

간단한 채팅을 위한 어플리케이션이 있다고 해보자 먼저 클라이언트 코드를 보면 아래와 같다.

❗️ 문제점 ❗️

현재는 user1이 user2에게 메시지를 보냈다고 할 때, user2가 메시지 받기(getMessage())를 하지 않으면 user2는 user1의 메시지를 받을 수 없다. 하여 메시지가 새로 올때마다 getMessage()를 해야 하는데, 이는 지나친 리소스 낭비다. 이를 polling으로 해결하려 해봐도 이 또한 리소스가 상당히 낭비되는 방법이다. 하여 옵저버 패턴을 적용하여 해결해보자

 

먼저 Sbcriber 인터페이스를 정의한다. User들은 Sbcriber가 된다.

 

이제 User는 이를 구현하면 된다. (User가 곧 옵저버이다.)

User는 이름만 가지고 있고, handleMessage는 단순히 들어온 메시지를 출력한다.

 

 

이제 Subject인 Subscriber

ChatServer는 옵저버들(user들)을 관리하고, sendMessage를 통해 변경사항을 받으면 구독중인 옵저버들이 제공하는 메소드(handleMessage)를 호출해준다.

 

클라이언트와 실행결과는 아래와 같다.

 

실행결과:

 

---

 

 

장점과 단점

 

정점

1. 상태를 변경하는 객체(publisher)와 변경을 감지하는 객체(subscriber)의 관계를 느슨하게 유지할 수 있다.

2. Subject의 상태 변경을 주기적으로 조회하지 않고 자동으로 감지할 수 있다.

3. 런타임에 옵저버를 추가하거나 제거할 수 있다.

 

단점

1. 복잡도가 증가한다.

2. 다수의 Observer 객체를 등록 이후 해지하지 않는다면 memory leak이 발생할 수도 있다.(WeakReference를 적용하면 어느정도 해결가능하지만 완전한 해결책은 아니다.)

 

 

 

 

 

 

 

같이 참조하면 좋은 글:

https://pjh3749.tistory.com/266

[디자인패턴] 옵저버 패턴 (Observer Pattern) 아주 간단하게 정리해보기