中介模式续

中介者模式进阶思考

通过上面的实例，可以看到，

①光驱、CPU、声卡、显卡这四个组件均继承同一个类Conlleague，且该抽象类中并没有中介者模式结构代码中定义的自身方法和依赖方法。

Java是单继承的，为了使用中介者模式，就让这些同事对象继承一个父类，且这个父类一般无法抽象出子类通用的的自身方法和依赖方法，仅仅是为了约束子类类型以及获取中介。 在实际开发中，很多相互交互的对象本身是没有公共父类的，所以无法做到示例代码中这样的结构。

②光驱、CPU、声卡、显卡这四个组件是通过将中介者作为其属性并通过构造方法传入来持有中介者对象的。

同事类持有中介类，无非是让中介者去调用掐其他同事类的方法。

实际应用中，可以把中介对象做成单例，直接在同事类的方法里面去调用中介者对象。

③具体中介者类只有一个，中介者接口有无存在必要？

在实际开发中，很常见的情况是不需要中介者接口的，而且中介者对象也不需要创建很多个实例，因为中介者是用来封装和处理同事对象的关系的，它一般是没有状态需要维护的，因此中介者通常可以实现成单例。

④中介者MotherBoard以私有属性的方式持有所有的同事，有必要吗？

虽说中介者对象需要知道所有的同事类，这样中介者才能与它们交互。但是是否需要做为属性这么强烈的依赖关系，而且中介者对象在不同的关系维护上，可能会需要不同的同事对象的实例，因此可以在中介者处理的方法里面去创建、或者获取、或者从参数传入需要的同事对象。

④中介者MotherBoard中只有一个方法，在方法内部又根据同同事类类型来处理，这个方法会不会太大了？

在实际开发中，通常会提供具体的业务通知方法，这样就不用再去判断到底是什么对象，具体是什么业务了。

实际开发中我们使用更多的是中介者模式的变种： 只要是实现封装对象之间的交互功能，就可以应用上中介者模式，而不必过于拘泥于中介者模式本身的结构。标准的中介者模式限制很多，导致能完全按照标准使用中介者模式的地方并不是很多，而且多集中在界面实现上。只要本质不变，稍稍变形一下，简化一下，或许能更好的使用中介者模式。

中介者模式和外观模式

这两个模式都是迪米特法则的应用，都是通过增加新的对象来解耦原来紧耦合的系统。

但外观模式多用来封装一个子系统内部的多个模块，目的是向子系统外部提供简单易用的接口，也就是说外观模式封装的是子系统外部和子系统内部模块间的交互；

而中介者模式是提供多个平等的同事对象之间交互关系的封装，一般是用在内部实现上。

另外，外观模式是实现单向的交互，是从子系统外部来调用子系统内部，不会反着来，而中介者模式实现的是内部多个模块间多向的交互。

中介者模式和观察者模式

这两个模式可以组合使用。 中介者模式可以组合使用观察者模式，来实现当同事对象发生改变的时候，通知中介对象，让中介对象去进行与其它相关对象的交互。

内容来自：《研磨设计模式--第10章 中介者模式（Mediator）》