답변:
Observer and Mediator, Design Patterns, Reusable Object-Oriented Software의 요소 라는 용어가 쓰여진 최초의 책 에서 옵저버 패턴을 사용하여 중재자 패턴을 구현할 수 있다고합니다. 그러나 동료 (관찰자 패턴의 주제와 거의 동일)가 중재자 클래스 또는 중재자 인터페이스에 대한 참조를 갖도록하여 구현할 수도 있습니다.
옵저버 패턴을 사용하려는 경우가 많이 있지만, 객체의 다른 객체가 상태를 관찰하는 것을 알지 않아야한다는 것이 핵심입니다.
중재자는 좀 더 구체적이며 클래스가 직접 중재자를 통해 통신하지 않도록합니다. 이를 통해 커뮤니케이션을 처리하는 클래스로 커뮤니케이션을 오프로드 할 수 있으므로 단일 책임 원칙이 도움이됩니다.
전형적인 중재자 예제는 GUI에 있으며 순진한 접근 방식은 "푸 (Foo) 패널이 비활성화되어 있고 막대 패널에"날짜를 입력하십시오 "라는 레이블이 있고 서버를 호출하지 않는 경우 버튼 클릭 이벤트에서 코드를 생성 할 수 있습니다. Mediator 패턴으로 "단지 버튼이고 Foo 패널과 Bar 패널의 레이블에 대해 잘 아는 비즈니스가 없으므로 서버에 전화를 걸면 중재자에게 물어볼 것입니다." 지금은 괜찮습니다. "
또는 관찰자 패턴을 사용하여 구현 된 경우 버튼에 "이봐, 관찰자 (조정자가 포함됨), 상태가 변경되었습니다 (누군가가 나를 클릭했습니다). 필자의 예에서는 아마도 이해가되지 않지만 때로는 그럴 것입니다. 관찰자와 중재자 사이의 차이는 코드 자체의 차이보다 의도의 하나입니다.
관찰자 패턴은 관찰자 간의 조정이 필요하지 않고 관찰 관계가 한 방향으로 진행될 때 잘 작동합니다 .
예를 들어, 오브젝트 B와 C가 오브젝트 A를 관찰하게하십시오. 오브젝트 A가 이벤트 X를 발생 시키면 오브젝트 B는 메소드 Y ()를 실행하고 오브젝트 C는 메소드 Z ()를 실행해야합니다. BY () 및 CZ () 메소드가 완전히 독립적이며 조정이 필요하지 않으면 옵저버 패턴을 사용하십시오.
반면, CZ () 전에 BY ()를 실행해야하는 경우 중재자가이 조정을 캡슐화하는 중재자 패턴을 사용하려고합니다. 이 시나리오에서 중개자 M은 오브젝트 A를 관찰하고 오브젝트 B 및 C에 대한 참조를 갖습니다. A가 이벤트 X를 발생 시키면 M은 이벤트를 처리하고 규정 된 순서로 BY () 및 CZ ()를 호출합니다.
또한 객체 A, B 및 C가 서로를 관찰해야하는 경우 중재자를 매개자로 사용하면 이러한 객체를 분리하고 스파게티 코드를 피할 수 있습니다.
이 Observer패턴은 한 클래스 (관찰 된 클래스)에서 수행 된 조치가 다른 클래스 (관찰 클래스)에서 반응을 생성해야하는 경우에 사용되지만 관찰 된 클래스가 관찰 클래스에 결합되는 것은 바람직하지 않습니다. 이것은 매우 일반적인 패턴입니다. SAX XML 파서는 좋은 예일 수 있습니다. SAX 구문 분석기를 사용하기 위해 클라이언트 ContentHandler는 구문 분석기 조작을 "관찰"하는 인터페이스를 구현합니다 . 파서가 XML 문서의 요소를 만나면의 메소드를 호출합니다 ContentHandler. 파서는 클라이언트 코드를 호출 할 수 있지만 파서는 클라이언트 코드에 연결되지 않습니다.
이 Mediator패턴은 일련의 객체 사용 패턴을 캡슐화 한 것입니다. 클라이언트 코드는 여러 다른 클래스에 연결되지 않고 중재자에만 연결됩니다. 캡슐화 된 개체의 수명이 중재자의 수명과 무관하다는 점을 제외하면 집계와 비슷합니다.