Observer Pattern과 Visitor Pattern

Observer Pattern

개념

객체 사이에 일 대 다의 의존 관계를 정의해 두어, 어떤 객체의 상태가 변할 때 그 객체에 의존성을 가진 다른 객체들이 그 변화를 통지받고 자동으로 갱신될 수 있게 만든 것. Observer 패턴에서 중요한 객체는 주체(subject)와 감시자(observer)이다. 주체는 독립된 여러 개의 감시가 있을 수 있다. 모든 감시자는 주체의 상태 변화가 있을 때마다 이 변화를 통보받는다. 각 감시자는 주체의 상태와 자신의 상태를 동기화시키기 위해 주체의 상태를 알아본다. 주체는 상태 변경에 대한 통보만 할 뿐 누가 감시자인지는 모른 채 통보를 한다.

활용

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

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

장점

• 옵저버 패턴은 MVC 모델에서 View단(사용자에게 보여주는 단계)에서 많이 나타날 수 있다, 객체의 상태에 대한 참조를 여러군데서 하고 있을 시에 (특히 여러개의 창에서 참조가 될 시에) 사용될 수 있다.

• 객체의 상태를 참조하는 대상에 일관성을 보장한다.

• 객체의 상태가 변경될 시에 참조를 하고있는 대상들은 자동으로 상태가 업데이트가 된다.

• 옵저버를 언제든지 추가할 수 있다.

• 새로운 형식의 옵저버를 추가하려고 할 때도 주체를 전혀 변경할 필요 없다.

• 주체와 옵저버를 서로 독립적으로 재사용할 수 있다.

• 주체나 옵저버가 바뀌더라도 서로에게 영향을 미치지 않는다.

단점

• 구독을 취소하는 동안 이벤트를 장담받을 수 없다.

Visitor Pattern

개념

Visitor Pattern은 알고리즘을 객체 구조에서 분리시키는 디자인 패턴이다. 이렇게 분리를 하면 구조를 수정하지 않고도 실질적으로 새로운 동작을 기존의 객체 구조에 추가할 수 있게 된다. 데이터 구조를 돌아다니며 알고리즘을 처리하는 구조이다.

<쉬운 예시> 이 패턴의 구조는 어느날 찾아온 잡상인을 생각하면 이해하기 쉽다. 잡상인은 온갖 물건들을 가지고 돌아다니며 나에게 맞는 물건또한 가지고 있다. 나는 그 많은 물건중 나에게 맞는것만 사면 되는것이다. 잡상인의 입장에서는 수많은 취향의 고객이 있는데, 다양한 취향을 만족시킬 수 있는 물건들을 미리 준비하여 고객들을 찾아다닐 수 있다. 이러한 형태를 클래스 구조로서 표현하게되면 Visitor pattern이 된다.

활용

1. 다양한 인터페이스를 갖는 수많은 객체들 안에 있는 데이터 작업을 수행할 때

2. Visitor 패턴은 개발자가 원하는 소스가 준비되어 있지 않거나 기타 다른 기술적인 이유로 소스 코드의 내용을 변경할 수 없는 경우 클래스 라이브러리나 프레임워크에 함수를 추가할 수 있는 유용한 방법이다. 개발자는 단지 프레임워크의 클래스를 서브클래스화하여 각각의 서브 클래스에 accept 메소드를 추가하면 된다.

장점

• 다양한 클래스의 수많은 인스턴스에서 가져온 데이터를 캡슐화할 때 유용하다.

• 클래스의 내용을 변경하지 않고 함수를 추가할 수 있다.

• 관련되지 않은 클래스들의 컬렉션에서 데이터를 얻을 수도 있고, 해당 데이터를 사용하여 사용자 프로그램에 대한 전역적인 연산결과를 얻을 수도 있다.

• 새로운 작업 내역을 추가하는 것이 쉽다. 그래서 더 이상 새로운 클래스의 생성이 필요로 하지 않는 시점에서 강력한 삽입 기능을 발휘할 수 있다.

단점

• 클래스에서 private 데이터는 얻을 수 없다.

• Visitor 인터페이스는 존재하는 타입들에 대해서 이미 정적으로 visit인터페이스를 정의하였기 때문에 새로운 타입에 대한 visit인터페이스를 추가하는 작업은 소스를 가지고있지 않은 사람이라면 불가능한 일이다.

• ConcreteElement 안에서 직접적으로 처리할때보다 연산에 오버헤드가 뒤따른다.