设计模式学习笔记

单件模式

保证一个类仅有一个实例，并提供一个访问它的全局访问点。单线程Static 或者GetInstance方法，多线程加锁。

简单工厂

通过一个Factory对象，创建各种对象，灵活性差。

抽象工厂

比如创建一个房屋对象，可能存在各种风格房屋的情况下，可以对房屋进行抽象。主要用来应对新系列的需求变动。

如果不存在”多系列对象创建“的需求变化，则没必要应用抽象模式，静态工厂方法足矣。

工厂方法

主要用于隔离类对象的使用者和具体类型之间的耦合关系。通过接口、抽象类实现。

建造者模式

主要用于“分步骤构建一个复杂的对象”。在这其中“分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。复杂构建过程封装为Builder,作为参数传给“分步骤”算法，由算法按步骤调用Builder的具体接口。

原型模式

依赖关系倒置, 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

原型模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些“易变类”拥有“稳定的接口”。

备忘录模式

必须保存一个对象某一个时刻的(部分)状态，这样以后需要时它才能恢复到先前的状态。创建一个状态恢复接口，接收状态对象并还原状态。

策略模式

对变化的算法进行抽象，并将对象作为参数传给统一的接口，比如各种排序算法可以抽象为多个排序策略。

责任链模式

模式的应用场合在于“一个请求可能有多个接受者，但是最后真正的接受者只有一个”，只有这时候请求发送者与接受者的耦合才胡可能出现“变化脆弱”的症状，职责链的目的就是将二者解耦，从而更好地应对变化。如果请求传递到职责链的未尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对象的责任，而不是发出请求的对象的责任。

下一个处理步骤对象，是通过参数传入的，而不是请求对象自己指定的。

中介者模式

用一个中介对象来封装一系列对象交互。中介者使各对象不需要相互引用，从而使其耦合松。散，而且可以独立地改变它们之间的交互。

将多个对象间复杂的关联关系解耦， Mediator 模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关系”为多“个对象和一个中介者关联”，简化了系统的维护，抵御了可能的变化。

例如，聊天室对象，统一调度所有聊天者的相互信息发送，聊天者对象之间不直接通信。

状态模式

允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。

State 模式将所有一个特定状态相关的行为都放入一个 State 的子类对象中，在对象状态切换时，切换相应的对象;但同时维持 State 的接口，这样实现了具体操作与状态转换之间的解耦。

命令模式

在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。

对不同的命令进行统一抽象，由激活器进行不同命令的统一接口调用。

模板方法

一个方法的执行步骤是统一的，将各个步骤作为抽象方法，由子类覆写。

适配器模式

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

外观模式

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

例如，业务层是将复杂数据访问逻辑进行封装后，给UI调用，减少前端代码复杂度。

享元模式

面向对象很好地解决了系统抽象性的问题，同时在大多数情况下，也不会损及系统的性能。但是，在某些特殊的应用中下，由于对象的数量太大，采用面向对象会给系统带来难以承受的内存开销。比如:图形应用中的图元等对象、字处理应用中的字符对象等。

字符可以通过享元模式，在内存中只创建一次对象，减少系统开销。

装饰器模式

动态地给一个对象添加一些额外的职责。就增加功能来说， Decorator 模式相比生成子类更为灵活。通过采用组合、而非继承的手法， Decorator 模式实现了在运行时动态地扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了单独使用继承带来的“灵活性差"和"多子类衍生问题"。

解释器模式

语法解析场景

组合模式

将实现统一接口的一系列对象添加到列表中，并由组合对象循环调用各个对象的统一接口。