设计模式（11）--Mediator中介者模式&Observer观察者模式

一、中介者模式理解起来很简单，即多个对象之间需要交互，那么这些对象间的交互就会形成网状结构。引入中介者，各对象根本不知道其它对象的存在，他们只需要把信息发送给中介者，由中介者来控制吧信息传递给哪些对象。所以，就变成了一个星形的结构。
中介者模式的目的很明显，就是为了解耦，但是缺点，也是比较明显，那就是中介者类本身会变得复杂，牵扯过多。所以，如果网状结构不是非常复杂，那么就不一定要考虑中介者。一旦使用了中介者，那么就需要谨慎的维护它，避免牵一发而动全身的错误。

二、观察者模式与中介者模式不同，观察者依赖于被观察者的状态改变，两者之间是需要交互的，我们常见的发布/订阅的说法就是观察者模式的一种。
1.观察者可以有很多类似行为，被观察者（主题）也有类似的行为，所以都可以抽象出来以形成解耦。这时候，notify()就可以调用vector中所有的观察者的update方法。
2.需要考虑的是有时候观察者的行为可能不一样，无法抽象出共性，比如观察者A要调用update()方法，但是B却是需要调用active()方法。这时候会导致的问题：
a.vector不能存放抽象类除非是Object泛型
b.notify无法统一的调用update方法。
那么当被观察者变化时，如果通知到所有的观察者呢？
（1）.NET中使用委托机制解决了这个问题，有兴趣可以稍微了解一下
（2）可Java怎么办呢？网上有人使用Map《Object,Method》来存储观察者对象和对应的方法，利用反射来实现类似委托机制的功能。
（3）java.util.Observable 类提供了一个被观察者结构，包括add delete观察者和notify方法。java.util.Observer抽象类提供了一个update抽象方法，即使是不同的类，也可以继承这个抽象类而在update中写不同的实现（就是强行将观察者A的update()和观察者B的active()同名到抽象方法中），来完成观察者模式。 这个结构不难，我们完全可以写出适合自己的结构来实现观察者模式。

总结一下，当许多类依赖某一个类的状态改变而做出反应时，就可以使用观察者模式。观察者模式的精髓在于notify和update。一定要保证被观察者调用notify即完成了通知的使命，而notify中也是简单的调用所有注册的观察者的update方法来完成响应。 只有这样，才是真正的解耦。
观察者模式有一个问题在于，例如java.util.Observable，使用了Vector和同步代码块。这就是说，所有注册的观察者，是一个顺序通知的形式，有者多线程并发问题和性能隐患。