본문 바로가기

Design/Design Pattern

[Design Pattern] Observer Pattern

이번 장에서는 옵저버(Observer) 패턴에 대해서 알아본다.
샘플 코드는 여기 (링크) 프로젝트의 테스트 코드로 정리해두었다.


옵저버 패턴이란?
위키백과에 따른 정의는 아래와 같다.

객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접
목록의 각 옵저버에게 통지하도록 하는 디자인 패턴이다.
주로 분산 이벤트 핸들링 시스템을 구현하는 데 사용된다. 발행/구독 모델로 알려져 있기도 하다.

설명이 쉽게 잘 나와있어서 쉽게 풀어 쓸 필요는 없을 듯하다.
중요한 점은 옵저버가 관찰하는 것이 아니라 관찰 당하는 객체가 자신의 변화를 옵저버에게 통지한다는 점이다.

필자는 서버 객체와 개발자 객체를 만들어 서버의 리소스 사용량이 일정 수치 이상이 되었을 때 개발자 객체에게 통지하는 코드를 작성해보겠다.


GoF Design Patterns에 따르면 아래와 같은 Class Diagram이 그려진다.

Subject: 관찰당하는 객체들의 인터페이스
ConcreteSubject: 관찰 당하는 구현체
Observer: 관찰하는 객체들의 인터페이스
ConcreteObserver: 실제로 관찰하는 구현체

위의 그림을 서버와 이를 관찰하는 개발자에 적용시키면 아래와 같은 Class Diagram이 그려진다.

감시당하는 Server들의 기능을 명시한 Server 추상 클래스가 있고 이를 확장(상속)한 ChattingServer, PushServer가 있다.

감시하는 Observer의 기능을 명시한 Observer 인터페이스가 있고 이를 정의한 Developer가 있다.
생성된 Developer는 자신이 담당하는 Server를 관찰하게 된다.


코드를 보면서 하나씩 살펴보도록 한다.

Server Class
CPU사용량과 Memory사용량을 가지고 있다.
자신의 상태를 알려줄 Observer 목록을 가지고 있으며 notify 메서드를 호출하면 Observer들에게 자신의 상태를 전송한다.

ChattingServer, PushServer Class
Server 추상 클래스를 확장(상속)한 클래스로써 CPU사용량 또는 Memory사용량이 임계치를 넘으면 Observer들에게 알리고 있다.

Observer Interface
관찰하는 Observer들의 기능을 명시하고 있다.

Developer Class
Observer의 구현체로 Server로부터 알림을 받은 내용을 출력하는 역할을 한다.

Tester Class
Server와 Observer를 생성하고 Observer들을 자신이 담당하는 Server에 attach 시키는 역할을 한다.

코드를 실행시킨 결과는 아래와 같다.


지금까지 Server와 Server를 감시하는 담당 개발자들을 예로 옵저버 패턴에 대해서 알아보았다.