距离上一次写设计模式总结已经有半个多月了，这一次我准备总结命令模式、职责链模式和中介者模式三个设计模式。
命令模式
文中举了小菜去吃烤肉串的例子，由于顾客较多老板频频出错。于是大鸟就说：“如果记录下哪个人需要几串羊肉串或者其他的要求，就不会这么容易出错了。在编码中，这就是行为请求者与行为实现者的紧耦合。需要对请求排队或者记录请求日志，以及支持可撤销的操作，这样就可以使得行为请求者与行为实现者的紧耦合化解。“
小菜按照大鸟的要求改了三趟代码，之后引入了命令模式的概念：
命令模式将一个请求封装为一个对象，从而使得你可以使用不同的请求对客户进行参数化：对请求排队或记录请求日志。以及支持可撤销的操作。
命令模式结构图如下：
最后总结了这个模式的作用：
- 他能较容易地设计一个命令队列。
- 在需要的情况下，可以较容易地将命令记入日志。
- 允许接收请求的一方决定是否要否决请求。
职责链模式
当类有太多的责任，便容易违背单一职责原则，增加新的管理类别，需要修改这个类，违背了开放-封闭原则。于是，我们利用多态性来化解过多责任引起的过多分支语句，大致想法是让负责各个责任的类有一定的关联，把用户的请求传递，直至解决这个请求。
于是引出职责链模式的定义：
职责链模式，使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连接成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。
职责链模式的结构图如下所示：
职责链模式的好处就是使得接收者和发送者不需要有对方明确信息，更能不用知道链的具体结构。于是，职责链相当于是一个黑盒，他简化了对象的相互连接，且链中的对象只用保持指向后继者的引用而不用保存接收者的引用。同时，程序员可以随时的添加删除职责链中的结构，具有很强的灵活性。
中介者模式
首先，尽管将一个系统分割成许多对象通常可以增加其可复用性，但对象之间相互连接的激增又会降低其可复用性。因为大量的连接使得一个对象不可能在没有其他对象的支持下工作，系统表现为一个不可分割的整体，所以，对系统的行为进行任何较大的改动就十分困难了。
于是，引入中介者模式解决该问题。中介者模式定义如下：
中介者模式用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
中介者模式如下所示：
中介者模式很容易在系统中应用，也很容易在系统中误用。当系统出现了多对多交互复杂对象群时，不要着急于使用中介模式，而是先反思是否是系统设计的不合理。
中介者模式一般用于一组对象已定义良好但是复杂的方式进行通讯的场合，比如刚才得到的窗体Form对象或Web页面aspx，以及想定制一个分布在多个类中的行为，而又不想生成太多子类的场合。
END