[헤드퍼스트 디자인패턴](2) 옵저버 패턴

 

: 객체들에게 연락 돌리기

 

 

소프트웨어 개발에서 바뀌지 않는 단 하나 = 변화

 

확장성 : 디스플레이 요소를 더하거나 뺄 수도 있다.

 

디자인 원칙

애플리케이션에서 달라지는 부분을 찾아내고 달라지지 않는 부분과 분리한다.

 

신문사 + 구독자 = 옵저버 패턴

신문사를 주제(subject), 구독자를 옵저버(observer)

 

느슨한 결합의 위력(Loose Coupling)

주제는 옵저버가 특정 인터페이스를 구현한다는 사실만 압니다.

옵저버는 언제든지 새로 추가할 수 있습니다.

새로운 형식의 옵저버를 추가할 때도 주제를 변경할 필요가 전혀 없습니다.

주제와 옵저버는 서로 독립적으로 재사용할 수 있습니다.

주제나 옵저버가 달라져도 서로에게 영향을 미치지 않습니다.

 

디자인 원칙

상호작용하는 객체 사이에는 가능하면 느슨한 결합을 사용해야 한다

 

---

디자인 원칙 경시대회

아래에 있는 각 디자인 원칙을 보고, 각 원칙이 옵저버 패턴에서 어떤 식으로 쓰이는지 설명해보세요.

 

애플리케이션에서 달라지는 부분을 찾아내고 달라지지 않는 부분과 분리한다

내답안

옵저버 패턴이라는 것은 결국에는 주제와 옵저버가 있는 것이고, 주제는 어떠한 이벤트에 따라서 옵저버에게 알림을 던져준다는 행위 자체는 변경이 안 되는 부분이다. 그리고 이 알림을 받아서 어떻게 처리할 것인지는 따라서 달라지는 부분이므로 각각의 옵저버에 알맞게 구현한다.

 

모범답안

옵저버 패턴에서 변하는 것은 주제의 상태와 옵저버의 개수, 형식입니다.

옵저버 패턴에서는 주제를 바꾸지 않고도 주제의 상태에 의존하는 객체들을 바꿀 수 있습니다. 나중에 바뀔 것을 대비해 두면 편하게 작업할 수 있습니다.

 

구현보다는 인터페이스에 맞춰서 프로그래밍한다

내답안

Subject 와 Observer 인터페이스를 만들고 각각을 구현한 클래스로 사용하므로써, 다양한 Observer를 생성해도 같은 인터페이스로 구현했기 때문에 변경없이 사용할 수 있습니다. 또 한 새로운 주제를 추가하게 되더라도 기존의 옵저버들은 동일하게 사용할 수 있습니다.

 

모범답안

주제와 옵저버에서 모두 인터페이스를 사용했습니다. 주제는 Subject 인터페이스로 Observer 인터페이스를 구현하는 객체들의 등록과 탈퇴를 관리하고, 그런 객체들에게 연락을 돌립니다. 이러면 지금까지 우리가 봐 왔던 것처럼 느슨한 결합을 만들 수 있습니다.

 

상속보다는 구성을 활용한다

내답안

옵저버에서 주제를 상속받는 식으로 쓰는게 아니라, 주제를 자신의 클래스에 멤버로 포함시켜서 사용하였습니다. 주제에 추가 기능이 생기더라도, 상속이 아니므로 새로운 인터페이스를 구현한 주제를 주입함으로써 변경에 대응할 수 있습니다.

 

모범답안

옵저버 패턴에서는 구성을 활용해서 옵저버들을 관리합니다. 주제와 옵저버 사이의 관계는 상속이 아니라 구성으로 이루어지니까요. 게다가 실행중에 구성되는 방식을 사용하니까 더할 나위 없이 좋겠죠.

 

 

옵저버 패턴으로 간단한 프로그램 하나 만들어 봤습니다.

https://github.com/DEVSI30/DefaultCheckBox

GitHub - DEVSI30/DefaultCheckBox

 

 

state(subject) 를 만들고 Observers(Component) 로 구독하여서 조금 복잡한 컴포넌트 동작을 처리하였습니다.