관찰자 패턴이란?
위키 백과
상태 변화를 관찰하는 관찰자들, 즉 옵저버들의 목록을 객체에 등록하여 상태의 변화가 발생할 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하는 디자인패턴이다.
특징
•
느슨한 결합이 가능하다.
•
알림이라는 키워드가 중요하다.
•
상태를 가지는 객체와 상태를 이용하는 객체를 구분해야 한다.
솔직히 이렇게 본다면 잘 이해가 안된다. 그래서 필자의 경우는 필자가 이해한 방식으로 관찰자 패턴을 정의해본다.
만약 우리가 오른쪽과 같은 데이터를 이용하여 각 부서의 전산에 보내주는 역할을 한다고 가정해보자.
그렇다면 우리는 보통의 경우 부서가 수입 지출 데이터를 가지고 가는 형태로 제작할 것이다. 근데 실시간으로 변화했을 때도 부서의 전산이 업데이트 되어야 한다면 어떻게 할까?
부서에서 [수입, 지출] 데이터를 계속 감지할 것이다. 이렇게 되면 어떻게 될까? 너무 당연하게도 매초, 매분, 매시간 마다 감지하는 배치를 돌려야한다. 이는 결국 자원을 소모한다.
그렇다면 [수입, 지출]이 자기가 변했다는 걸 부서에 전달하면 어떨까? 이 의문이 들고 생각났다면 더 이상 안봐도 된다.
관찰자 패턴을 적용하기 전
아래와 같이 [수입, 지출] 데이터를 가져오기 위해서 변화감지, 업데이트 등을 부서전산마다 만들어줘야한다.
관찰자 패턴을 적용하기
관찰자 패턴을 적용하게 된다면 주제가 자신을 관찰하는 관찰자 타입을 가지고 있고(여기서 가지고 있다는 말은 알림을 어떻게 줄까?에 대한 방법을 가지고 있는 것이다), 이 타입을 이용하여 주제 자체가 가지고 있는 데이터의 변화가 생기면 가지고 가라고 알리는 것이다.
관찰자 패턴 이해하기
관찰자 패턴이란?
위키 백과
상태 변화를 관찰하는 관찰자들, 즉 옵저버들의 목록을 객체에 등록하여 상태의 변화가 발생할 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하는 디자인패턴이다.
수입 지출 데이터가 주제고 부서가 관찰자구나! 주제에서 변화가 생기면 그냥 알려주는거네
특징•
느슨한 결합이 가능하다.
화살표의 방향이 반대로 되었구나. 또한 직접적으로 부서를 호출하는 것이 아닌 관찰자 타입으로 호출하구나•
알림이라는 키워드가 중요하다.
주제가 알리는 방법을 가지고 있구나. 이를 관찰자 타입(Observer)으로 통일해서 주제에 담아서 관리하네•
상태를 가지는 객체와 상태를 이용하는 객체를 구분해야 한다.
데이터가 주제가 되고, 이 데이터를 이용하는 친구들이 관찰자이다.
Subject - 주제 (여기서는 [수입,지출] 데이터가 될 것이다.)
notifyObservers() - 관찰자 타입의 notify()들을 호출하는 통합된 방법이다.
Observer - 관찰자 타입 (여기에는 필히 알림 방법을 적어준다.)
ConcreteObserverA, ConcreteObserverB - 관찰자 타입 : {영업부, 경리부, 사회사업부, 회계부}
관찰자 패턴은 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 알림 메서드를 호출한다. 라는 말을 이제는 이해했을 것이라고 믿는다.
이런 의문이 들 수 있다. 각 부서마다 감지하는게 더 편할 것 같은데? 이 패턴 역시 확장성을 고려한다. 만약 잠깐 생겼다가 사라지는 팝업부서가 생겼다. 그럼 감지하는 역할을 또 구현할 것인가? 아니다.