设计模式思想总结

0.首要意识：

        重构是通往良好的设计模式之路， 重构要不断进行， 设计模式也需要灵活变化（但是一定要有好设计的追求）。目的是为了写出 高内聚低耦合，符合软件具体情况的可靠、健壮、可读、可复用、可维护的优雅架构和模块。 误用模式会有很大害处，不用模式也会有很大害处，结合情景正确灵活的使用23种设计模式或者自己构造更加合适的模式才是正确之路。 （遇到太复杂混乱的模块和架构，一定要记得用设计模式来分离逻辑，无论是用23种设计模式/继承设计/面向过程/泛化设计等实现更好的设计）。

设计模式是设计更恰当的自身，设计模块管理器接口，设计模块之间和总体的架构关系图，实现高内聚和低耦合的模块和模块之间的通信。设计模式如果牵强的说也可以说是设计管理器。 创建型模式，就是 对象创建管理器 ；结构型模式是 类/模块之间的结构管理器 ；行为型模式是 对象/模块之间的通信行为管理器 。

23种设计模式：

创建型5种：

工厂模式/方法，抽象工厂模式; 单例模式, builder构建模式，prototype模式。

结构型模式7种：

bridge桥接模式和adapter适配模式；decorate装饰模式，composite组合模式，Proxy代理模式。facade门面模式，flyweight享元模式。

行为模式11种：

template模板模式，strategy策略模式，state状态模式；observer观察者模式，mediator中介者模式。

iterator迭代器模式，memento备忘录模式，interpreter解释器模式； command命令模式，chain of resposibility责任链模式。

部分模式解析：

一、创建型模式:
创建型模式比较简单，就是关于对象创建的管理，单例，builder逐步构建，prototype原型拷贝。

二、结构型模式（abcd pff)：
adapter适配器模式是适配，也就是关联一个功能类的意思提供适配的接口给外部client，分为类继承适配和对象组合适配。

bridge桥接模式是将业务需求和算法实现分离（通过组合而不是继承)，业务有业务的抽象和子类，实现也是一样。他们之间通过业务基类关联实现算法基类来联系。 业务类可以灵活的使用实现算法，实现算法拓展也方便。使得实现算法和业务类分离。

composite组合模式，组合模式和装饰模式一样，但是组合重在管理各个业务子类，提供各种各样的组合体；装饰重在实现装饰的子类可以方便的和被装饰的对象配合，提供各种各样的装饰体。

decorate装饰模式，对象和装饰体拥有同样的基类，且装饰体关联了对象基类，装饰体可以灵活的去装饰不同的对象类，为内部对象类和装饰类切换搭配比较自如。这样不用继承深度和频繁的修改继承基类的函数等。

proxy代理委托模式，也类似装饰模式只是专注于一个接口类子类的代理实现。

FlyWeight享元模式，创建了一个没有的对象那么先保存起来，如果有就查找返回，设计内存池对象池时候常用，也是性能优化的常用方法。

facade门面模式，门面模式关联组合了多个系统，对外提供统一的接口，socket就是用了Facade模式，很多结构管理器都用了门面模式，是非常实用的。

三、行为型模式(template strategy state, observer mediator visitor; iterator memento interpreter, command chain of responsibility)：

template模板模式，通过继承的多态来实现，高层设计好调用框架，子类底层实现多态依赖于高层的调用框架，也是设计中的依赖倒置原则。

strategy策略模式，在template中重用子类的实现就比较麻烦，需要频繁修改父类的接口；策略模式通过将调用框架设计在strategy类中，重用多态子类和修改组合不同子类就比较容易，使得调用框架和实现功能类分离开，整个设计比较松散耦合，核心频繁修改模块中一定要记得多采用strategy模式代替template模式，当然template模式在自身逻辑实现功能中也不可或缺。

State状态模式，状态模式是将跳转状态控制和动作逻辑分离，在大量switch case跳转中可以用上。跳转状态维护一个State子类指针目的是执行时候用具体逻辑由State子类处理，state模式也和strategy模式类似，只是state模式的实现子类基类维护了一个到跳转状态控制Action的指针，目的是State子类也可以调用Action类实现状态转换，这样跳转状态控制需要拓展时候在Action端修改即可，逻辑处理在State子类拓展或修改。实现了跳转控制Action类和动作业务处理State类分离，但是跳转的动作处理类毕竟是一个个State类，类的开销比较大，除非状态不多，否则还是用map管理类进行跳转动作到动作处理类的映射比较好，当然状态少时用C风格的switch case也是可以使用的。

Observer观察者模式，一个subject类维护一份数据和一个相关的数据表现类的基类指针数组，当数据改变时notify所有数据表现类；subject类的数据状态输入端可以是外部类，也可以数据表现类来改变；subject也可以有自己的子类，方便拓展。

Mediator中介者模式，对象间相互通信交织在一起，不如提供一个中间者，其他对象只需要维护和中间者的通信，中间者管理和跳转他们所需要的通信。体现了单一职责和集中管理的原则。当中介者模式管理的类比较复杂数目巨大时候，需要考虑桥接模式/策略模式/门面模式来对中介者模式进行拆分，否则中介者模式会导致比较难以维护。

Visitor访问者模式，试图解决双分派的问题，也就是两个多态对象问题，通过相互依赖对方，每个业务逻辑需要一个子类，同时相应的业务子类也需要一个访问子类，访问子类注册给业务逻辑子类，访问子类反转回调业务子类的逻辑。这样每增加一个业务或者变更就需要写两个子类，耦合度比较高。但是分离了访问模块和业务子类逻辑，总比全部揉在一起频繁父类子类修改好。更好的方法是用C风格的函数指针和map数据结构存放类型和处理函数的映射来实现双分派，避免需要大量的类，且实现了很好的可复用。

iterator迭代器模式，利用泛化和关联需要遍历的容器，对多种类型容器，提供统一的遍历方式。

Memento备忘录模式 ，一个状态逻辑类关联一个备忘类，备忘类有来自状态逻辑类的输入函数和到状态逻辑的输出函数，这样提供undo功能，备忘录也可以有自己的基类这样匹配统一处理更多的状态逻辑类。

interpreter解释器模式，解释器基类关联一个内容类，内容类提供不同的内容，解释器需要对不同的内容进行解释器，所以需要不同的解释器子类，解释器子类关联了一个内容类，且解释器子类拥有解释器基类的指针，如果是非终结类那么自己解释不了的会分发给自己的子类来解释，解释器子类自己能够解释的就自己解释了。xml文件的解释模块，编译器文法分析都需要用到解释器模式。

command命令模式，将所有的命令或者请求定义为命令子类，命令子类关联各自的命令处理（Deal with)类。命令处理类可以提前注册给命令类，也可以使用的时候注册命令处理类。提供统一的命令基类接口，外部消息invoke关联命令基类接口只需要产生命令子类并用命令基类excute执行命令即可，真正的执行命令是命令子类注册的命令处理子类。在较复杂的请求和请求分类处理逻辑中可以抽象出命令子类和命令模式，避免复杂的凌乱的穿插处理。

chain of resposibility责任链模式，是一个消息或者命令状态的分发模式，有一个handle基类提供处理消息状态的接口，和可以关联本身类型的特性，处理定义消息或者状态类型，每个handle子类有自己的消息处理函数映射表，如果没有找到处理该消息的函数，那么将该消息分发给关联类处理，直到全部没有处理那么提供一个默认的类进行处理责任消息或者命令状态。