[디자인 패턴]Observer Pattern

옷가게에서 일할 때 있었던 일이다. 우리는 무작위적으로 할인 행사를 열었는데 타이밍을 놓친 손님들이 한결같이 투덜거리고는 했다. 할인 할 때 문자 좀 주면 좋겠다고. 매번 며칠 전까지 할인 했다는 걸 알고 나면 속상하다고. 옵저버 패턴은 이러한 손님들을 위한 문자 발송과 같다.

“관찰자”라는 단어를 보면 해당 이름표를 달고 있는 객체는 어떠한 역할을 수행할 것 같은가?  누군가를 면밀히 지켜보는 역할은 아닐까? 옵저버 패턴에서는 이 옵저버의 의미가 조금 다르다. 단순히 지켜본다, 보다는 `연락을 기다린다`라는 것이 더 옳은 표현일 것이다. 

마치 옷가게 할인 행사 문자를 기다리는 손님과 같다. 옷가게를 주시하고, 관찰하지만 결국 옷가게에서 문자를 보내주어야 손님은 행동을 결정할 수 있다. 옷가게를 들릴지, 들리지 않을지 그리고 옷을 살지, 사지 않을 지.  그리고 옷들을 둘러보다가 또다시 결정을 내릴 것이다. 여전히 이 옷가게의 알림 문자를 받을지, 받지 않을지. 이러한 과정을 패턴화 한 것을 옵저버 패턴이라고 한다. 

알람을 보내는 옷가게를 Subject, 손님들을 Observer라고 한다.

이러한 옵저버 패턴을 사용하면 손님들도 본인들의 책임을 다 할 순간을 정확하게 알 수 있기에 불필요한 조회가 필요치 않다. 또한 가게를 뜯어 고칠 필요 없이 새로운 손님의 번호만 추가하면 되기 때문에  SOLID 법칙에서 확장에는 열려 있고 변경에는 닫혀 있는 Open-Close Principle 개방 폐쇄 법칙을 잘 지킬 수 있다. 게다가 언제든지 옷가게와의 관계를 손님이 끊을 수 있기에 무조건적인 관계가 아니라는 장점이 있다. 이때 손님은 언제든지 이러한 관계를 끊을 수 있는데 이는 손님과 옷가게는 할인 행사에 대한 알림을 주고 받거나, 주고 받지 않는 관계라는 전제가 삶 속에 존재하기 때문이다. 즉, 앱이 실행되는 런타임에도 이러한 관계가 미리 정해져 있기에 이에 대한 업데이트가 가능하다.

다만 손님들이 알림 문자를 받는 타이밍은 무작위적이기에 마음대로 정할 수 없다. 또한 손님이 더 이상 이 옷가게를 오지 않기로 마음 먹었지만 번호 삭제하는 것을 잊었다면, 불필요한 문자를 받게 되어 옷가게나 손님 모두 서로의 자원을 낭비하는 결과를 낳을 수 있다. 프로그램 상으로는 메모리 누수가 생기게 되는 것이다. 게다가 이 패턴을 자주 사용한다면 구조와 동작이 점점 복잡해지고 알아보기가 힘들어진다. 

때문에 이러한 장단점을 고려해 적절한 사용이 필요하다.