디자인 패턴 - 옵저버 패턴

안녕하세요.

 

이번 글에서는 디자인패턴 중 옵저버 패턴에 대해서

 

학습하고 기억하기 위하여 글을 작성 하게 되었습니다.

---

디자인 패턴에 대해서도 상당히 많은 패턴들이 존재하는데요..

이번 글에서 다룰 옵저버 패턴, 및 

 

싱글턴 패턴, 상태 패턴, 이벤트 버스 패턴, 커맨드 패턴, 방문자 패턴, 전략 패턴, 데커레이너 패턴,

어댑터 패턴, 퍼사드 패턴, 서비스 로케이터 패턴 등..

 

 

unity 프로젝트에는 직접 사용한 경험은 없지만, 수많은 패턴들이 존재하며..

 

이름만 들어본 패턴 및, 아예 처음 들어보는 것도 있었습니다..

 

 

심지어 싱글턴 패턴은, 제가 사용한다고 사용했는데 좀 더 알아보니

 

제가 작성한 Script는 싱글턴 패턴이 아닌, 단 순 static 변수 클래스라고 읽는 게 맞다는 이야기도 들어서..

 

 

상당히 혼란스럽기도 하고, 걱정이 많이 되긴 하는데...

 

포기는 절대 하지 않고 천천히 하나씩 학습을 하며 알아가 보겠습니다.

 

---

 

우선, 디자인패턴 - 이란 어느 한 프로그래밍 언어나 소프트웨어에서만 제한되는 것이 아니라

 

여러 프로그래밍 언어와 소프트웨어에서도 충분히 적용할 수 있는 유용한 내용이라고 합니다.

 

 

기존의 패턴을 참고하여 새로운 패턴을 만들어 적용을 할 수 있고,

 

각 프로젝트와 상황 및 팀의 개발 규칙에 따라 비슷하지만 다른 새로운 패턴을 적용할 수 있다고 하는데요.

 

디자인 패턴을 사용하는 가장 주는 협업과 유지보수에 있다고 한다고 합니다.

 

 

그 중에서도 이번 글 에서는, 옵저버 패턴(Observer pattern)에 대해서 학습 및 알아 보고자 합니다.

 

우선, 옵저버 패턴의 장.단점 에 대해서 공부를 해 보았습니다.

 

옵저버 패턴 - 어떤 '이벤트'가 일어나는 것을 감시하는 패턴을 의미.

---

*장점 중 일부

역동성 : 주체에 필요한 만큼의 객체를 관찰자로 추가할 수 있으며, 런타임에 동적으로 제거할 수도 있다.

일대다 : 옵저버 패턴의 주요 이점은 일대다 관계가 있는 객체 간 이벤트 처리 시스템의 구현 문제를 우아하게 해결한다는 점이다.

 

*단점 중 일부

무질서 : 옵저버 패턴은 관찰자가 알림받는 순서를 보장하지 않는다. 둘 이상의 옵저버 객체가 종속성을 공유하고 특정 순서에 맞춰 함께 작동해야만 한다면 기본 형태의 옵저버 패턴은 적당하지 않다. 기본 옵저버 패턴은 이런 종류의 실행을 다루도록 설계되지 않았다.

누수 : 주체는 관찰자에 대한 강한 참조를 가져 메모리 누수를 일으킬 수 있다. 제대로 분리 및 삭제되지 않았는데 패턴을 잘못 구현하고 관찰자 객체가 더 이상 필요하지 않은 경우 가비지 컬렉션 에서 문제를 일으킬 수 있으며 일부 리소스는 해제되지 않는다.

 

*유니티로 배우는 게임 디자인 패턴 (제2판) -참고-

---

흠.. 일단은 장.단점을 읽어본 결과 얼핏 알 것 같으면서도 잘 이해가 되지 않는 부분도 있고..

 

직접 사용해 본것이 아니라 와닿지 않아서 그런것 일수 있는데..

 

그래서 간략하게 나마 (저 에게)이해를 돕기 위하여

 

직접 코딩을 해보며 학습해 보기로 했습니다.

 

일단 단순히 옵저버 추상 클래스를 구현해 주고

 

옵저버를 상속받은 클래스에서 함수 실행을 시켜주는 모습 입니다.

 

단순히 abstract를 이용해 자식 클래스에서 '재정의'를 강제화 하고

 

override를 이용하여 '재정의'를 해 주는 모습 같은데.. 

 

아직 잘 모르겠습니다..

 

---

글을 여러개 찾아 보았습니다.

 

Subject interface 입니다.

 

주석과 마찬 가지로 등록, 해제, 갱신을 위함 입니다.

 

Observer interface 입니다.

 

update 함수에 인자로 value가 넘어 옵니다.

 

ConcreteSubject 클래스는 Subject interface를 상속 받습니다.

 

그리고 ArrayList를 사용하여 observer의 정보를 가지고 있습니다.

 

Observer interface를 상속 받는 A,B 클래스 입니다.

 

똑같은 클래스가 중복 된 것 이며, 각 클래스의 생성자(ctor) 에서 ConcreteSubject를 인자로 받고,

 

registerObjerver를 호출하여 자신을 옵저버로서 등록을 합니다.

 

마지막 으로 Main 프로그램 입니다.

 

COncreteSubject 및 A, B 인스턴스를 생성하는데, A, B의 각 인스턴스가 옵저버로서

 

ConcreteSubject 인스턴스에 등록 됩니다.

 

마지막 줄인 setValue(10)을 호출 하면 모든 옵저버의 update가 호출 됩니다.

---

글 들을 찾아 보면서 작성된 코드를 직접 코딩 하여 작성을 해 보았는데도,

 

아직 크게 와닿지가 않는것 같습니다..

 

어렴풋이 알 것 같으면서도, 아무것도 없는 상태에서

 

직접 프로젝트에 사용 및 구현을 해보라고 하면

 

상당히 어렵다고 느낄것 같은데.. 

 

좀 더 다른 예시들과 함께 다양한 방식들을 찾아 봐야 할 것 같습니다.

 

 

정말 간략하게 요약을 하자면, 일대다 관계를 이루고 있으며

 

상태가 업데이트되면 모든 옵저버들에게 정보를 갱신 할 수 있도록 만드는 것을 의미한다고 하며,

 

조금 더 풀어 쓰자면, 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들한테

 

연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다 (One - To - Many) 의존성을 정의 한다고 합니다.

 

 

이번 글에서 다룬 내용은 가장 기본적인 옵저버 패턴의 동작이며, 

 

많이 사용되고, MVC 패턴을 사용하기 위한 기초 개념이니 꼭 익혀두길 권장한다고도 쓰여 있습니다.

 

꼭 마스터 까진 아니여도 원리를 익히겠습니다.

 

감사합니다.