设计模式（续一）

    这一周按顺序具体看了下面几个模式，感觉理解是加深了，下面陈列+自述一下它们的特点：

代理模式，拥有公共接口的实体类和引用该实体类的类的模式。当实体类不便于具体实例化或不便于进行某些操作时，通过“代理”类来引用实体类达到应用的目的。引用大话设计模式的一句话“代理模式其实就是在访问对象时引入一定程度的间接性，因为这种间接性，可以附加多种用途”。

    工厂模式，在简单工厂模式的基础上对工厂类进行抽象提炼为接口，而实现接口的具体工厂类和产品类一一对应。这样就符合了开放-封闭的原则：没有修改、只是拓展。    

    原型模式，类通过一接口实现对自身的浅复制或深复制。简化了类实例化的过程，只通过已实例化的对象的一个方法即可实现对该对象的复制，这“既隐藏了对象创建的细节，又对性能是大大的提高”

    模板方法模式，一组具有相似操作方式的类，通过抽取、提炼相似点建构出提供实现这些方法模板的抽象的父类。相应子类根据需要覆写父类的方法实现各相应子类的“不同”的方法。“当我们要完成在某一细节层次一致的一个过程或一系列步骤，但其个别步骤在更详细的层次上的实现可能不同时，我们通常考虑使用模板方法模式来处理”，这样就”提供了一个很好的代码复用平台“。

    迪米特法则：如果两个类只有很少的联系，那么它们之间的通信不应直接通过关联来通信，应通过第三者来进行转发。这样降低了类之间的耦合--“类之间的耦合越弱，越有利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及”。

    外观模式：“外观”类封装了对其他类的实例化和方法调用，使得对其他类的实例化和调用变的简单。”外观模式（Facade），为子系统的一组接口提供一个一致的界面，此模式定义一个高层接口，这个接口使得这一子系统更加容易使用。“
    建造者模式：零件很多，但其生产模式相似，通过定义零件生产的接口IProduct使它们的实现有章可依。而产品建造者实现接口IProduct并且实现装配且可返回产品、指挥者则通过接口IProduct实现具体产品建造者对具体产品的零件装配过程，这样就使具体产品的零件组装对外隐藏。“建造者模式的好处就是使得建造代码与表示代码分离，由于建造者隐藏了该产品是如何组装的，所以若需要改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了。”

    观察者模式：由于通知者通知内容的不确定性和观察者的数量和接受通知不同的问题，抽象出抽象通知者（或接口）和抽象观察者（或接口）。抽象通知者保存对所有观察者的引用，并可添加、删除观察者对象；抽象观察者为具体的观察者提供更新的接口（接受具体通知者的通知）。抽象观察者有时不大灵活，于是有了事件委托（可动态添加对一些方法的引用），大大方便了通知者发出通知后观察者的响应的灵活性。

    抽象工厂模式：“实现了多个产品系列的加工过程，这就使得改变一个应用的具体工厂变得容易，它只需改变具体工厂即可使用不同的产品配置。它让具体的创建实例过程与客户端相分离，客户端是通过它们的抽象接口操作实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户端代码中。”缺点是：代码需增加时代码变动太大。简单工厂改进的模式虽然解决了代码变动、耦合问题，但也引入了switch选择语句，违反了开放-封闭原则。而反射+配置文件的方式完美解决了上述问题（认识中）

    状态模式：当对象中集中了过多的对状态选择的情况时，使用状态模式。通过把与状态相关的行为与对象隔离封装，使当状态行为有所变化时不至于违反开放-封闭原则去更改对象的代码。“状态模式通过把各种状态转移逻辑分布到State子类之间，来减少相互间的依赖。”

    适配器模式：现有对象想访问原有对象而接口不符时、两个类所作的事情相同或相似但是具有不同的接口时，使用状态模式。“双方都不太容易修改的时候再使用适配器模式”