设计模式2

第十一章：迪米特法则

迪米特法则（又称：最少知识原则）：如果两个类不必彼此直接通信，那么这两个类

就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

在类的结构设计上，每一个类都应当尽量降低成员的访问权限。

迪米特法则其根本思想，是强调了类之间的松耦合。类之间的耦合越弱，越有利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及。

第十二章：外观模式

外观模式（Facade）：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

首先，在设计的初期阶段，应该要有意识的将不同的两个层分离。

其次，在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂。增加外观模式

可以提供一个简单的接口，减少它们之间的依赖。

第三，在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，为新系统开发一个外观模式类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与外观模式对象交互，外观模式与遗留代码交互所有复杂的工作。

第十三章：建造者模式

建造者模式（Builder），将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

建造者模式的好处就是使得建造代码与表示代码分离，由于建造者隐藏了该产品时如何组装的，所以若需要改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了。

建造者模式是在当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时适用的模式。

第十四章：观察者模式

观察者模式：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己。

使用场合：

当一个对象的改变需要同时改变其他对象的时候；一个抽象模型有两个方面，其中一方面依赖于另一方面，这时用观察者模式可以将这两者封装在独立的对象中使他们各自独立的改变和复用。

观察者模式所做的工作其实就是在解除耦合。让耦合的双方都依赖于抽象，而不是依赖于具体。从而使得各自的变化都不会影响另一边的变化。

第十五章：抽象工厂模式

抽象工厂模式（Abstract Factory），提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

第十六章：状态模式

状态模式（State）：当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。

适用场合：该模式主要解决的是当控制一个对象状态转换的调解表达式过于复杂时的情况，把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。

优点：将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。

当一个对象的行为取决于它的状态并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式了。

第十七章：适配器模式

适配器模式（Adapter）：将一个类的接口转换成客户希望的另外一个接口。该模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

适用场合：主要应用于希望复用一些限制的类，但是接口又与复用环境要求不一致的情况。

第十八章：备忘录模式

备忘录（memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可将该对象恢复到原先保存的状态。

适用场合：该模式比较适用于功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的属性只是众多属性中的一小部分时。

当角色的状态改变的时候，有可能这个状态无效，这时候就可以使用暂时存储起来的备忘录将状态复原。

缺点：角色状态需要完整存储到备忘录对象中，如果状态数据很大很多，那么在资源消耗上，备忘录对象非常消耗内存。

第十九章：组合模式

组合模式（Composite）：将对象组合成树形结构以表示“部分-整体”的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。

适用场合：

需求中是体现部分与整体层次的结构时，希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑使用组合模式了。

第二十章：迭代器模式

迭代器模式（Iterator）：提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示。

迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据。

第二十一章：单例模式

单例模式（singleton），保证一个类仅有一个实例，并提供一个访问它的全局访问点。

让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，并且它可以提供一个访问该实例的方法。

第二十二章：桥接模式

合成/聚合复用原则（CARP），尽量使用合成/聚合，尽量不要使用类继承。

优点：优先使用对象的合成/聚合将有助于你保持每个类被封装，并将集中在单个任务上。这样类和类继承层次会保持较小规模，并不太可能增长为不可控制的庞然大物。

聚合表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分；

合成则是一种强的“拥有”关系，体现了严格的部分和整体的关系。

桥接模式（bridge），将抽象部分与它的实现部分分离，使它们都可以独立地变化。

实现指的是抽象类和它的派生类用来实现自己的对象。

由于实现的方式有多种，桥接模式的核心意图就是把这些实现独立出来，让他们各自的变化。这就使得每种实现的变化不会影响其他实现，从而达到应对变化的目的。

第二十三章：命令模式

命令模式（Command），将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作；

优点：

第一，它能较容易地设计一个命令队列；

第二，在需要的情况下，可用较容易地将命令记入日志；

第三，允许接收请求的一方决定是否否决请假；

第四，可以容易地实现对请假的撤销和重做；

第五，由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易。

最后，把请求一个操作的对象与知道怎么执行一个操作的对象分隔开。

敏捷开发原则告诉我们，不要为代码添加基于猜测的，实际不需要的功能。如果不清楚一个系统

是否需要命令模式，一般不要着急去实现它，事实上，在需要的时候通过重构实现这个模式并不困难，只有在真正需要如撤销/恢复操作等功能时，把原来的嗲吗重构为命令模式才有意义。

第二十四章：职责链模式

职责链模式：使多个对象都有机会处理请求，从而避免请假的发送者和接受者直接的耦合关系。将这个对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。

第二十五章：中介者模式

中介者模式（Mediator），用一个中介对象来封装一系列的对象交互。中介者是各对象不需要显示的相互作用，从而使其耦合松散，而且可以独立的改变他们之间的交互。

优点：中介者模式一般应用于一组对象以定义良好的但是复杂的方式进行通信的场合。

第二十六章：享元模式

享元模式（Flyweight），运营共享技术有效的支持大量细粒度的对象。

享元模式可以避免大量非常相似的开销。在程序设计中，有时候需要生成大量细粒度的类实例来表示数据。如果能发现这些实例除了几个参数外基本上都是相同的，有时候就能够受大幅度地减少需要实例化的类的数量。如果能把这些参数移到类实例的外面，在方法调用时将它们传递进来，就可以通过共享大幅度地减少单个实例的数目。

适用场合：如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用；还有就是对象的大多数状态可以外部状态，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象，此时可以考虑使用享元模式。

第二十七章：解释器模式

解释器模式（Interpreter），给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

适用于：有一个语言需要解释执行，并且你可经该语句中的句子表示为一个抽象语法树时，可使用解释器模式。

第二十八章：访问者模式

访问者模式（Visitor），表示一个作用于某个对象结构中的各元素的操作。它使你可用在不改变各元素的类的前提下定义作用于这些元素的新操作。

适用于：访问者模式的目的是要把处理从数据结构分离出来。如果有比较稳定的数据结构，又有易于变化的算法的话，使用访问者模式就是比较合适的，因为访问者模式使得算法操作的增加变得容易。

优点：增加新的操作很容易，因为增加新的操作就意味着增加一个新的访问者。访问者模式将有关的行为集中到一个访问者对象中。

缺点：使增加新的数据结构变得困难。

第二十九章：模式总结

《完》