옵저버 패턴이란 무엇일까? 옵저버하면 스타크래프트에서 나오는 프로토스 정찰 비행선이 생각난다.

그 비행선처럼 무언가 감지하여 우리가 알 수 있게 해주는 그런 패턴일까??? 옵저버 패턴이 무엇인지 알아보자.

옵저버 패턴이란?

· 객체 사이에 일 대 다의 의존 관계를 정의해 두어, 어떤 객체의 상태가 변할 때 그 객체에 의존성을 가진 다른 객체들이 그 변화를 통지받고 자동으로 갱신될 수 있게 만드는 패턴.

※ 감시자 패턴, 종속자(Dependent) 패턴, 게시-구독(Publish-Subscribe) 패턴이라고도 불림.

· 옵저버 패턴에서 가장 중요한 객체는 주체(Subject)와 감시자(Observer)

- 주체는 독립된 여러 개의 감시가 있을 수 있음.

- 모든 감시자는 주체의 상태 변화가 있을 때마다 이 변화를 통보 받음.

- 각 감시자는 주체의 상태와 자신의 상태를 동기화시키기 위해 주체의 상태를 알아봄.

※ 위와 같은 상호작용을 게시-구독 관계라고 함. 주체는 상태 변경에 대한 통보를 하는 것이므로 누가 감시자인지 모른 채 통보를 발송, 불특정 다수의 감시자가 이 통보를 수신하기 위해서 구독을 신청하는 것.

이제는 옵저버 패턴이 무엇인지 어느정도 의미를 알았지만 과연 이 패턴을 언제 사용해야 할지 막막할것이다. 언제 옵저버 패턴을 사용해야 할지 간략하게 알아보자.

언제 옵저버 패턴을 사용해야 할까?

· 어떤 추상 개념이 두 가지 양상을 갖고 하나가 다른 하나에 종속적일 때.

· 한 객체에 가해진 변경으로 다른 객체를 변경해야 하고, 프로그래머들은 얼마나 많은 객체들이 변경되어야 하는지 몰라도 될 때.

· 어떤 객체가 다른 객체에 자신의 변화를 통보할 수 있는데, 그 변화에 관심있어 하는 객체들이 누구인지에 대한 가정 없이도 그러한 통보가 될 때.

구조

· Subject : 감시자들을 알고 있는 주체. 임의 개수의 감시자 객체는 주체를 감시할 수 있음. 주체는 감시자 객체를 붙이거나 떼는 데 필요한 인터페이스를 제공함.

· Observer : 주체에 생긴 변화에 관심 있는 객체를 갱신하는데 필요한 인터페이스를 정의함. 이로써 주체의 변경에 따라 변화되어야 하는 객체드르이 일관성을 유지할 수 있음.

· ConcreteSubject : ConcreteObserver 객체에게 알려주어야 하는 상태를 저장함. 또한 이 상태가 변경될 때 감시자에게 변경을 통보함.

· ConcreteObserver : ConcreteSubject 객체에 대한 참조자를 관리함. 주체의 상태와 일관성을 유지해야 하는 상태를 저장함. 주체의 상태와 감시자의 상태를 일관되게 유지하는 데 갱신 인터페이스를 구현.

옵저버 패턴의 장점

· Subject와 Observer 클래스 간에는 추상적이며 최소한의 결합도만이 존재함.

· 브로드캐스트(broadcast) 방식의 교류를 가능하게 함.

· 예측하지 못한 정보를 갱신함.

옵저버 패턴의 예

· MCV 모델 (모델 == Subject / 뷰 == Observer)

[참고] GoF의 디자인 패턴

객체지향 소프트웨어를 설계하는 것은 쉬운 일이 아니다. 게다가, 재사용할 수 있는 객체지향 소프트웨어를 만드는 것은 더욱 힘든 일이다.

이처럼 힘든 일인 올바른 객체지향 소프트웨어를 만드는 것을 보다 쉽게 할 수 있게끔 도와주는 것이 있는데, 이것이 바로 디자인 패턴이다. 지금부터 디자인 패턴이 무엇인지 알아보자.

"각 디자인 패턴은 기존 환경 내에서 반복적으로 일어나는 문제들을 설명한 후, 그 문제들에 대한 해법의 핵심을 설명해 줍니다. 똑같은 방법으로 두 번 하지 않고 이 해법을 100만 번 이상 재사용할 수 있도록 말이죠."

- 건축가이자 패턴의 아버지, 크리스토퍼 알렉산더 -

디자인 패턴이란?

· 특정한 전후 관계에서 일반적 설계 문제를 해결하기 위해 상호교류하는 수정 가능한 객체와 클래스들에 대한 설명.

· 설계에서 얻은 세세한 경험들을 다른 사람이 응용하기 좋도록 자세히 기록한 것.

패턴에 들어가는 네 가지 요소

· 패턴 이름(Pattern name)

패턴 이름은 한두 단어로 설계 문제와 해법을 서술함. 패턴의 의도를 표현하고 설계에 대한 생각을 쉽게 함.

· 문제(Problem)

문제는 언제 패턴을 사용하는 가를 서술하며 해결할 문제와 그 배경을 설명함.

· 해법(Solution)

해법은 설계를 구성하는 요소들과 그 요소들 간의 관계, 책임 그리고 협력 관계를 서술함.

구체적인 부분을 제시하지 않고 문제에 대한 추상적인 설명을 제공하고 문제를 해결하기 위해서 클래스나 객체들의 나열 방법을 제공함.

· 결과(Consequence)

결과는 디자인 패턴을 적용해서 얻는 결과와 장단점을 서술함. 소프트웨어에서의 결과란 가끔 시간이나 공간 사이의 균형일 수도 있음. 즉, 시간을 중요한 요소로 볼 것인지 저장 공간의 효율을 중요한 요소로 볼 것인지에 따라 다른 설계 방법을 선택해야 함.

패턴 분류 기준

· 목적(purpose)

· 범위(scope)

목적

패턴이 무엇을 하는지 정의 하는 것.

크게 생성, 구조, 행동 중의 하나의 목적을 가짐.

· 생성

객체의 생성 과정에 관여하는 패턴.

· 구조

클래스나 객체의 합성에 관한 패턴.

· 행동

클래스나 객체들이 상호작용하는 방법과 책임을 분산하는 방법을 정의하는 패턴.

범위

패턴을 주로 클래스에 적용하는지 아니면 객체에 적용하는지를 구분하는 것.

크게 클래스 패턴과 객체 패턴으로 구분.

· 클래스 패턴

클래스와 서브클래스 간의 관련성을 다루는 패턴.

관련성은 주로 상속이며 컴파일 타임에 정적으로 결정

· 객체 패턴

객체 관련성을 다루는 패턴.

런타임에 변경할 수 있으며 더 동적인 성격을 가짐.

[참고] GoF의 디자인 패턴