23种设计模式(四)

设计模式(Java版)

 

说明：本资源是本人学习需要，通过网上查询，摘取网上有关设计模式好的解释，再由个人整理而得，绝对详解，看代码时最好结合word文档的图解一起，学习使用 

源码和文档下载：http://download.csdn.net/detail/u010651186/7736041

设计模式分为三大类：

创建型，共五种：单例模式、静态工厂模式(普通工厂)、抽象工厂模式、建造者模式、原型模式。

结构型，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型，共十一种：策略模式、模板方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

行为型：

19.备忘录模式（memento）

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

适用：

    1.必须保存一个对象在某一时刻(部分)的状态，这样以后需要时它才能恢复到先前的状态。

    2.如果用一个接口来让其他对象直接得到这个状态，将会暴露对象的实现细节并破坏对象的封装性。

20.状态模式（state）

（这个模式允许你可以在运行时很容易地根据自身内部的状态改变对象的行为）

适用：

    1.当一个对象的转换条件表达式过于复杂时，通常这个状态由一个或者多个枚举表示，通常有多个操作包含这一相同的的条件结构，state模式将一个条件分支放到一个类中，这使得你可以根据对象自身的情况将对象的状态作为对象，这一对象不依赖于其他对象而独立变化，把状态的判断逻辑放到表示不同状态的一系列类中。

    2.一个对象的行为取决于它的状态，并且它必须在运行时根据状态立即改变行为。

21.访问者模式（visitor）

（分离对象的数据和行为，可以实现不修改已有类的情况下，增加新的操作[访问者]）

适用：

    1一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。

　　2 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Visitor使得你可以将相关的操作集中起来定义在一个类中。

　　3 当该对象结构被很多应用共享时，用Visitor模式让每个应用仅包含需要用到的操作。

　　4 定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。

22.中介者模式（mediator）

（中介者模式也是用来降低类类之间的耦合的，因为如果类类之间有依赖关系的话，不利于功能的拓展和维护；修改一个对象，其它关联的对象都得进行修改；如果使用中介者模式，只需关心和Mediator类的关系，具体类类之间的关系及调度交给Mediator就行）

适用:

    1.一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。

    2.一个对象引用很多其他对象并直接与这些对象通信，导致难以复用该对象。

    3.想定制一个分部在多个类中的行为，而又不想生成太多的子类

23.解释器模式（interpreter）

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

   （1）抽象表达式(Expression)角色：声明一个所有的具体表达式角色都需要实现的抽象接口。这个接口主要是一个interpret()方法，称做解释操作。

　　（2）终结符表达式(Terminal Expression)角色：实现了抽象表达式角色所要求的接口，主要是一个interpret()方法；文法中的每一个终结符都有一个具体终结表达式与之相对应。比如有一个简单的公式R=R1+R2，在里面R1和R2就是终结符，对应的解析R1和R2的解释器就是终结符表达式。

　　（3）非终结符表达式(Nonterminal Expression)角色：文法中的每一条规则都需要一个具体的非终结符表达式，非终结符表达式一般是文法中的运算符或者其他关键字，比如公式R=R1+R2中，“+"就是非终结符，解析“+”的解释器就是一个非终结符表达式。

　　（4）环境(Context)角色：这个角色的任务一般是用来存放文法中各个终结符所对应的具体值，比如R=R1+R2，我们给R1赋值100，给R2赋值200。这些信息需要存放到环境角色中，很多情况下我们使用Map来充当环境角色就足够了。

 

适用:

    当一个语言需要解释执行，并且你可以将该语句中的句子表示为一个抽象语法树时，可使用解释器模式。而当存在以下情况时该模式效果最好。

    1.该文法简单对于复杂的文法，文法的类层次变得庞大而无法管理。

    2.效率不是一个关键问题，最高效的解释器通常不是通过直接解析语法分析树实现的，而是首先将他们转换成另一种形式。