【设计模式】总结篇之六大设计原则与二十三种设计模式

总结

看完了六大设计原则与书中的二十三种设计模式。如果要说收获了什么，当然是遇到问题时需要考虑到的问题。在写代码的时候不仅做到满足功能，如果一个产品的代码仅仅只是为了满足功能，那么可以预想到的是也许这个产品在初代还是能够满足需求，但是在以后的维护和扩展中会造成很大的麻烦，因为你得代码一旦需要增加功能或者需求改变，需要修改的代码量将是会等于重新整个产品。
而学习设计模式的思想会帮助我们在遇到产品功能设计的时候考虑到的是扩展性可修改性尽可能的让每个功能独立，做到功能间的高内聚，模块间的低耦合。而不是将代码都码在一起，也许大家都会有这样的情况，在写代码的时候尚且还能够认识自己的代码，但是过一段时间后，看到自己写的代码都会发呆一会儿，这就是把全部功能都码在一起的缺点之一。当然最重要的是不易于扩展，要知道产品做出来是为了服务人，而人又是个善变的物种，所以不可避免的会遇到功能修改，需求增加的情况。所以在写代码的时候养成一个好习惯是必要的。
总之不要迷信任何一个模式，但是需要时刻记住设计原则。没有完美的设计模式，只有完美的满足需求功能。

六大设计原则

单一职责原则

应该有且仅有一个原因引起类的变更。

里氏替换原则

只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常,使用者可能根本就不需要知道是父类还是子类。
但是,反过来就不行了,有子类出现的地方,父类未必就能适应。

依赖倒置原则

高层模块不应该依赖底层模块，两个都应该依赖抽象
依赖倒置原则的本质就是面向接口编程，利用接口抽象类实现各个类或模块间实现独立，不相互影响，实现模块间的松耦合。

接口隔离原则

就是尽量把接口细化。注意与单一职责原则的区别，单一职责不一定接口是最细化的。

迪米特法则

只需要知道提供的方法或接口是实现的什么目的，至于怎么去实现不关心。

开闭原则

当发生变化时，开闭原则要求我们通过扩展实现实现变化。

二十三种设计模式

单例模式

确保某一个类只有一个实例,而且自行实例化并向整个系统提供这个实例。
饿汉模式，懒汉模式

工厂方法模式

定义一个用于创建对象的接口,让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
一个抽象类产品多个具体类产品，通过抽象工厂的具体工厂实现相应的产品

抽象工厂模式

为创建一组相关或相互依赖的对象提供一个接口,而且无须指定它们的具体类。
有N个产品族，就应该有N个创建方法；有M个产品等级就应该有M个实现工厂类，实现不同产品族的生产任务

模板方法模式

定义一个操作中的算法的框架,而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
抽象类：基本方法由子类实现，模板方法一般是一个具体方法，实现对基本方法的调度，完成固有的逻辑

建造者模式

将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
建造者模式关注的是零件类型和装配工艺(顺序)

代理模式

为其他对象提供一种代理以控制对这个对象的访问。
具体的角色就是实际的业务逻辑，不用关心其他非本职责的事务；具体的角色随时都会发生变化，但是只要实现了接口，代理类可以不做任何修改就可以使用

原型模式

用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。
不通过new关键字产生一个对象，而是通过对象复制来实现

中介者模式

用一个中介对象封装一系列的对象交互,中介者使各对象不需要显示地相互作用,从而使其耦合松散,而且可以独立地改变它们之间的交互。
适用于多个对象之间紧密耦合的情况，在类图中出现了蜘蛛网状结构，可以考虑使用中介者模式，使得蜘蛛网状结构变成星型结构

命令模式

将一个请求封装成一个对象,从而让你使用不同的请求把客户端参数化,对请求排队或者记录请求日志,可以提供命令的撤销和恢复功能。
经典命令模式：甲方向项目经理提需求，项目经理让程序员实现

责任链模式

使多个对象都有机会处理请求,从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有对象处理它为止。
将请求和处理分开，将处理者和请求这解耦提高系统的灵活性，一个请求在一条责任链上递送，直到被解决

装饰模式

动态地给一个对象添加一些额外的职责。就增加功能来说,装饰模式相比生成子类更为灵活。
对继承的补充，继承是静态的增加功能，装饰模式是动态的增加功能；

策略模式

定义一组算法,将每个算法都封装起来,并且使它们之间可以互换。
减少大量if-else和case的办法，在特定的环境使用想用的算法

适配器模式

让两个没有任何关系的类在一起运行;适配器模式是一个补偿模式，或者说是一个补救模式

迭代器模式

已经被各种主流编程语言实现了

组合模式

对于“部分-整体”问题的优先解决方案

观察者模式

也叫做发布订阅模式(Publish/subscribe),通过监听被观察者的动作获取信息做出相应的动作

门面模式

把复杂的子系统，通过一个或多个门面类与客户端交互

备忘录模式

记录一个对象的状态，使得对象在状态改变之后，还能回到过去保存的状态

访问者模式

访问类，在类的内部添加方法实现访问者的逻辑

状态模式

由每个状态管理该状态的处理逻辑，以及转换到另一个状态的逻辑

解释器模式

是一种按照规定语法进行解析的方案

享元模式

把复杂的对象分离出共享的对象部分，减少内存的占用

桥梁模式

当继承的方法无法满足需求，可以将基类的方法释放出去，用桥梁搭过去实现