대의원 대 관찰자의 패턴

Question

간접 협회와 옵저버에게 대의원을 사용해야하는 경우에 대한 지침이 있습니까?

C#에서는 간단한 콜백을 위해 대리인을 사용할 수 있습니다. 함수에 대한 포인터와 멤버 함수에 대한 포인터가 델리게이트로 간주 될 수 있다고 생각합니다 (맞습니까?).

나는 관찰자를 사용하고, 인터페이스를 생성하고, 구현해야하므로 더 강하게 입력되고 관계가 더 공식적이라는 것을 깨닫는다. 델리게이트의 경우 함수 서명과 접근 가능성이 일치하는 한 "연결"할 수 있습니다.

대리인이 옵저버 패턴을 moot로 만듭니다. 대의원과 관찰자의 패턴을 어떻게 결정합니까?

Answer 1

옵저버 패턴은 이미 events의 형태로 구현되어 있습니다.

이벤트의 장점은 여러 가입자를 보유 할 수 있다는 것입니다. 단, 대표단은 하나만 가질 수 있습니다. 이것은 공개 인터페이스와 이벤트 발생을 알리는 사람을 완벽하게 제어 할 수없는 시나리오에서 이벤트를 훨씬 잘 만듭니다. 실제로 이벤트는 자동으로 관리되는 대리인 목록입니다. 시나리오에서 무엇이 더 합리적인지 알아야합니다.

편집 :As commenter Rabbi mentions 위의 내용은 모든 대리인이 멀티 캐스트 대리인이 될 수 있으므로 완전히 사실이 아닙니다. 이벤트 수정 자의 목적은 이벤트 수정자를 정의한 클래스 내에서만 호출 할 수있는 대리자를 만드는 것입니다. 이것은 공용 인터페이스에서 캡슐화를 보장하는 데 가장 유용합니다.

Answer 2

대리인을 사용하여 관찰자 패턴을 구현할 수 있습니다. 이벤트를 생각해보십시오. 그것은 당신이 선호하는 경우 위임을 사용하여로 그 리팩토링 많이받지 않을 것 http://www.dofactory.com/Patterns/PatternObserver.aspx

: 이벤트 여기를 살펴없이

그것을 할.

인터페이스 구현과 관련하여 생각할 수있는 유일한 이점은 모든 구현에서 멤버 이름의 일관성입니다.

Answer 3

관찰자 패턴의 한 가지 이점은 일반적으로 관심있는 사람이 많은 수의 이벤트를 구독하는 경우 단일 개체를 이벤트에 가입하는 방법으로 전달하면 구독하는 것보다 훨씬 쉽습니다. 각 이벤트를 개별적으로. C#에서 익명 클래스 인 as can be done with Java에 대한 인터페이스와 메서드를 지정하지 않으면 관찰자 패턴을 구현하는 것이 약간 힘들어 지므로 대부분 이벤트를 사용하는 것이 좋습니다.

전통적인 옵저버 패턴의 또 다른 이점은 어떤 이유로 가입자에게 질문 할 필요가있을 때 더 잘 처리된다는 것입니다. 위와 같은 문제는 웹 서비스 경계를 ​​통과하는 객체를 필요로합니다. 옵저버 패턴은 단순히 다른 객체에 대한 참조 일 뿐이지 만 직렬화가 객체 내의 참조 무결성을 유지하는 한 잘 작동합니다. NetDataContractSerializer와 같은 그래프가 나타납니다. 이러한 경우 참조 된 구독자가 동일한 개체 그래프 내에 있는지 여부에 따라 서비스 경계를 ​​만들기 전에 제거해야하는 구독자를 구분할 수 있습니다.