Mediator Vs Observer面向对象的设计模式

Question

我一直在阅读四人帮,以解决我的一些问题,并遇到了Mediator模式.

我之前在项目中使用了Observer来制作一些GUI应用程序.我有点困惑,因为我发现两者之间没有太大区别.我浏览找到差异,但找不到任何适合我的查询的答案.

有人可以帮助我区分两者,并用一些明确划分两者的好例子吗？

Answer 1

Observer模式:定义对象之间的一对多依赖关系,以便当一个对象更改状态时,将自动通知和更新其所有依赖项.

介体模式:定义一个封装一组对象如何交互的对象.Mediator通过使对象明确地相互引用来促进松散耦合,并且它允许您独立地改变它们的交互.

来源:dofactory

例:

观察者模式:A类,可以有零个或多个O型观察者注册它.当A中的某些内容发生变化时,它会通知所有观察者.

中介模式:你有一些X类实例(或者甚至是几种不同的类型:X,Y和Z),并且它们希望彼此通信(但你不希望每个实例都有明确的引用因此,您创建一个中介类M.每个X实例都有一个M的共享实例的引用,通过它可以与X(或X,Y和Z)的其他实例进行通信.

Answer 2

在创造了Observer和Mediator,Design Patterns,可重用面向对象软件的元素这一术语的原始书中,它说可以通过使用观察者模式来实现Mediator模式.但是,也可以通过让同事(大致相当于Observer模式的主题)引用Mediator类或Mediator接口来实现它.

在许多情况下,当您想要使用观察者模式时,关键是对象不应该知道其他对象正在观察它的状态.

Mediator更具体一点,它避免让课程直接沟通,而是通过调解员沟通.这有助于单一责任原则,允许将通信卸载到刚刚处理通信的类.

一个典型的Mediator示例位于GUI中,其中天真的方法可能会导致按钮单击事件上的代码说"如果Foo面板被禁用且Bar面板上有标签说"请输入日期",则不要调用服务器,否则继续",在Mediator模式中,它可以说"我只是一个按钮,并且没有关于Foo面板和Bar面板上的标签的世俗事务,所以我只是问我的调解员是否调用服务器现在还可以."

或者,如果Mediator是使用观察者模式实现的,那么按钮会说"嘿,观察者(包括调解员),我的状态发生了变化(有人点击了我).如果你关心,可以做点什么".在我的例子中,可能没有意义,然后直接引用中介,但在许多情况下使用Observer模式实现Mediator是有意义的,Observer和Mediator之间的差异将更多的是意图而不是代码本身的差异.

Answer 3

观察

没有

• Client1:嘿主题,你什么时候改变？

• Client2:你什么时候改变主题？我没有注意到!

• Client3:我知道Subject已经改变了.

随着

• 客户保持沉默.
• 一段时间以后 ...
• 主题:亲爱的客户,我已经改变了!

中间人

没有

• Client1:嘿Taxi1,带我去哪儿.
• Client2:嘿Taxi1,带我去哪儿.
• Client1:嘿Taxi2,带我去哪儿.
• Client2:嘿Taxi2,带我去哪儿.

随着

• 客户1:嘿TaxiCenter,请带我一辆出租车.
• 客户2:嘿TaxiCenter,请带我一辆出租车.

Answer 4

这些模式用于不同的情况:

当您有两个具有某种依赖关系的子系统并且其中一个子系统需要更改时,使用介体模式,并且由于您可能不想更改依赖于另一个的系统,您可能需要引入一个介体,解耦它们之间的依赖关系.这样,当其中一个子系统发生变化时,您所要做的就是更新中介.

当一个类想要允许其他类自己注册并在事件上接收通知时使用观察者模式,例如ButtonListener等.

这两种模式都允许较少的耦合,但是完全不同.

Answer 5

让我们举个例子：假设你想构建两个应用程序：

1. 聊天应用程序。
2. 紧急救护车操作员应用程序。

调解人

构建聊天应用程序，您将选择mediator设计模式。

• 这些人可能在任何给定时间加入和离开聊天，因此在聊天的两个人之间保持直接参考是没有任何意义的。
• 我们仍然需要促进两个人之间的交流并允许他们聊天。

为什么我们会更喜欢mediator? 看看它的定义：

使用中介者模式，对象之间的通信被封装在中介者对象中。对象不再直接相互通信，而是通过中介进行通信。这减少了通信对象之间的依赖关系，从而减少了耦合。

魔法是如何运作的？首先，我们将创建聊天中介，并使人对象注册到它，因此它将与每个人有两个定向连接（该人可以使用聊天中介发送消息，因为它可以访问它，而聊天中介将访问人对象的接收方法，因为他也可以访问它）

function Person(name) {
    let self = this;
    this._name = name;
    this._chat = null;

    this._receive(from, message) {        
        console.log("{0}: '{1}'".format(from.name(), message));
    }
    this._send(to, message) {
        this._chat.message(this, to, message);
    }
    return {
        receive: (from, message) => { self._receive(from, message) },
        send: (to, message) => { self._send(to, message) },
        initChat: (chat) => { this._chat = chat; },
        name: () => { return this._name; }
    }
}


function ChatMediator() {
    let self = this;
    this._persons = [];    

    return {
        message: function (from, to, message) {
            if (self._persons.indexOf(to) > -1) {
                self._persons[to].receive(from, message);
            }
        },
        register: function (person) {
            person.initChat(self);
            self._persons.push(person);
        }
        unRegister: function (person) {
            person.initChat(null);
            delete self._persons[person.name()];
        }
    }
};

//Usage:
let chat = new ChatMediator();

let colton = new Person('Colton');
let ronan = new Person('Ronan');

chat.register(colton);
chat.register(ronan);

colton.send(colton, 'Hello there, nice to meet you');
ronan.send(ronan, 'Nice to meet you to');

colton.send(colton, 'Goodbye!');
chat.unRegister(colton);

观察者

构建 911 呼叫应用程序，您将选择observer设计模式。

• 每个救护observer对象都希望在出现紧急状态时得到通知，以便他可以驱动地址并提供帮助。
• 应急操作员会observable参考每辆救护车observers，并在需要帮助（或发生事件）时通知他们。

为什么我们会更喜欢observer? 看看它的定义：

称为主体的对象维护其依赖项列表，称为观察者，并通常通过调用它们的方法之一自动通知它们任何状态更改。

function AmbulanceObserver(name) {
    let self = this;
    this._name = name;
    this._send(address) {
        console.log(this._name + ' has been sent to the address: ' + address);
    }
    return {
        send: (address) => { self._send(address) },
        name: () => { return this._name; }
    }
}


function OperatorObservable() {
    let self = this;
    this._ambulances = [];    

    return {
        send: function (ambulance, address) {
            if (self._ambulances.indexOf(ambulance) > -1) {
                self._ambulances[ambulance].send(address);
            }
        },
        register: function (ambulance) {
            self._ambulances.push(ambulance);
        }
        unRegister: function (ambulance) {
            delete self._ambulances[ambulance.name()];
        }
    }
};

//Usage:
let operator = new OperatorObservable();

let amb111 = new AmbulanceObserver('111');
let amb112 = new AmbulanceObserver('112');

operator.register(amb111);
operator.register(amb112);

operator.send(amb111, '27010 La Sierra Lane Austin, MN 000');
operator.unRegister(amb111);

operator.send(amb112, '97011 La Sierra Lane Austin, BN 111');
operator.unRegister(amb112);

差异：

1. 聊天mediator在人对象之间有两种通信方式（发送和接收），而操作员observable只有一种通信方式（它告诉救护车observer行驶和完成）。
2. 聊天mediator可以使人对象之间进行交互（即使不是直接通信），救护车observers只注册操作员observable事件。
3. 每个 person 对象都有一个对 chat 的引用mediator，并且 chatmediator保持对每个人的引用。救护车observer不参考操作员observable，只有操作员observable参考每辆救护车observer。

Answer 6

@cdc 很好地解释了意图的差异。

我会在上面添加更多信息。

Observer：启用将一个对象中的事件通知给不同的一组对象（不同类的实例）

中介器：集中从特定类创建的一组对象之间的通信。

来自dofactory的 Mediator 模式的结构：

Mediator：定义同事之间通信的接口。

Colleague：是一个抽象类，定义了Colleagues之间要通信的事件

ConcreteMediator：通过协调Colleague对象实现合作行为并维护其同事

ConcreteColleague : 实现通过Mediator收到的通知操作，已经由其他同事生成

一个真实世界的例子：

您正在维护网状拓扑中的计算机网络。如果添加了新计算机或删除了现有计算机，则该网络中的所有其他计算机都应该知道这两个事件。

让我们看看 Mediator 模式如何融入其中。

代码片段：

import java.util.List;
import java.util.ArrayList;

/* Define the contract for communication between Colleagues. 
   Implementation is left to ConcreteMediator */
interface Mediator{
    public void register(Colleague colleague);
    public void unregister(Colleague colleague);
}
/* Define the contract for notification events from Mediator. 
   Implementation is left to ConcreteColleague
*/
abstract class Colleague{
    private Mediator mediator;
    private String name;

    public Colleague(Mediator mediator,String name){
        this.mediator = mediator;
        this.name = name;
    }
    public String toString(){
        return name;
    }
    public abstract void receiveRegisterNotification(Colleague colleague);
    public abstract void receiveUnRegisterNotification(Colleague colleague);    
}
/*  Process notification event raised by other Colleague through Mediator.   
*/
class ComputerColleague extends Colleague {
    private Mediator mediator;

    public ComputerColleague(Mediator mediator,String name){
        super(mediator,name);
    }
    public  void receiveRegisterNotification(Colleague colleague){
        System.out.println("New Computer register event with name:"+colleague+
        ": received @"+this);
        // Send further messages to this new Colleague from now onwards
    }
    public  void receiveUnRegisterNotification(Colleague colleague){
        System.out.println("Computer left unregister event with name:"+colleague+
        ":received @"+this);
        // Do not send further messages to this Colleague from now onwards
    }
}
/* Act as a central hub for communication between different Colleagues. 
   Notifies all Concrete Colleagues on occurrence of an event
*/
class NetworkMediator implements Mediator{
    List<Colleague> colleagues = new ArrayList<Colleague>();

    public NetworkMediator(){

    }

    public void register(Colleague colleague){
        colleagues.add(colleague);
        for (Colleague other : colleagues){
            if ( other != colleague){
                other.receiveRegisterNotification(colleague);
            }
        }
    }
    public void unregister(Colleague colleague){
        colleagues.remove(colleague);
        for (Colleague other : colleagues){
            other.receiveUnRegisterNotification(colleague);
        }
    }
}

public class MediatorPatternDemo{
    public static void main(String args[]){
        Mediator mediator = new NetworkMediator();
        ComputerColleague colleague1 = new ComputerColleague(mediator,"Eagle");
        ComputerColleague colleague2 = new ComputerColleague(mediator,"Ostrich");
        ComputerColleague colleague3 = new ComputerColleague(mediator,"Penguin");
        mediator.register(colleague1);
        mediator.register(colleague2);
        mediator.register(colleague3);
        mediator.unregister(colleague1);
    }
}

输出：

New Computer register event with name:Ostrich: received @Eagle
New Computer register event with name:Penguin: received @Eagle
New Computer register event with name:Penguin: received @Ostrich
Computer left unregister event with name:Eagle:received @Ostrich
Computer left unregister event with name:Eagle:received @Penguin

解释：

1. Eagle首先通过注册事件加入网络。没有通知任何其他同事，因为 Eagle 是第一个。
2. 当Ostrich添加到网络时，Eagle会收到通知：输出的第 1 行现在已渲染。
3. 当Penguin添加到网络时，Eagle和Ostrich 都已收到通知：现在渲染输出的第 2 行和第 3 行。
4. 当Eagle通过注销事件离开网络时，Ostrich和Penguin都已收到通知。现在呈现输出的第 4 行和第 5 行。

Answer 7

尽管它们都是用于组织状态变化的方式，但在结构和语义上它们与IMO略有不同。

观察者用于从对象本身广播特定对象的状态更改。因此，更改发生在还负责发出信号的中央对象中。但是，在调解器中，状态更改可以在任何对象中发生，但可以通过调解器广播。因此流程有所不同。但是，我认为这不会影响我们的代码行为。我们可以使用一个或另一个来实现相同的行为。另一方面，这种差异可能会对代码的概念理解产生一些影响。

可见，使用模式的主要目的是在开发人员之间创建通用语言。因此，当我看到调解人时，我个人理解尝试通过单个代理/集线器进行通信以减少通信噪音（或促进SRP）的多个元素，并且每个对象在具有发出状态更改信号的能力方面同样重要。例如，考虑有多架飞机接近机场。每个人都应该通过定向塔（调解人）进行交流，而不是相互交流。（以为有1000架飞机在降落时互相通信-太混乱了）

但是，当我看到观察者时，这意味着我可能会担心某些状态更改，因此应该注册/订阅以侦听特定的状态更改。有一个中央对象负责发出状态更改信号。例如，如果我在关心从A到B途中的特定机场，我可以注册到该机场以捕获广播的某些事件，例如，如果有空跑道或类似的跑道。

希望清楚。