设计模式总结

看完了 Head First 设计模式，收获还是蛮多的，这么多设计模式总算有了个了解，距离实用还有一定距离，毕竟是个经验活，不得不说设计模式中的思想真是太棒了！后面有几种模式没时间拿出来单独研究了，在这里就都战略性总结一下吧，啊哈哈~~
希望我也能写出一手漂亮的代码！

设计原则

一览表：

设计原则名称	定义	使用频率
单一职责原则 (Single Responsibility Principle, SRP)	一个类只负责一个功能领域中的相应职责	★★★★☆
开闭原则 (Open-Closed Principle, OCP)	软件实体应对扩展开放，而对修改关闭	★★★★★
里氏代换原则 (Liskov Substitution Principle, LSP)	所有引用基类对象的地方能够透明地使用其子类的对象	★★★★★
依赖倒转原则 (Dependence Inversion Principle, DIP)	抽象不应该依赖于细节，细节应该依赖于抽象	★★★★★
接口隔离原则 (Interface Segregation Principle, ISP)	使用多个专门的接口，而不使用单一的总接口	★★☆☆☆
合成复用原则 (Composite Reuse Principle, CRP)	尽量使用对象组合，而不是继承来达到复用的目的	★★★★☆
迪米特法则 (Law of Demeter, LoD)	一个软件实体应当尽可能少地与其他实体发生相互作用	★★★☆☆

基本的设计原则

上面的表中都是专业的说法，但是貌似并不怎么好理解，反正我是看的比较懵逼，然后就用普通的语言来进行描述下，首先是下面总结的几条，应该是大纲级别的了

封装变化
找出应用中可能需要变化的部分，把它们独立出来；不要和那些不需要变化的代码混在一起
针对接口编程，而不是针对实现编程
多用组合，少用继承
为交互对象之间的松耦合设计而努力

这样设计类才能更好的利用 OO 的特性，也是基础：抽象、封装、继承、多态；
良好的 OO 设计必须具备：可复用、可扩充、可维护三个特性

对上面不太好理解的地方补充：
松耦合：
当两个对象之间松耦合，它们依然可以交互，但是不太清楚彼此的细节；也就是说，如果改变其中一方并不会影响到另一方，因为两者是松耦合的，所以只有它们之间的接口仍被遵守，那么我们就可以自由的改变它们（接口的重要性）
松耦合的设计之所以能建立起富有弹性的 OO 系统，能够应对变化，是因为对象之间的互相依赖降到了最低。

开闭原则

从表中也可以看出，这个使用的非常频繁，开闭原则是面向对象的可复用设计的第一块基石，它是最重要的面向对象设计原则；它规定：类应该对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。
我们的目标是允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为；装饰模式就是遵守的这个原则的体现（硬要说，观察者模式也是遵循的）
当然，并不是让每个地方都遵循开闭原则（这回增加代码的复杂度），我们要把注意力集中在最有可能改变的地方，然后应用开闭原则

依赖倒置原则

规定的是：要依赖抽象，而不是依赖具体的类；emmm，和“针对接口编程，而不是针对实现编程”貌似是差不多的
它说明：不能让高层组件依赖低层组件，而且，不管高层或者低层组件，两者都应该依赖于抽象！

所谓高层组件，是由其他低层组件定义其行为的类。
就比如人类是高层组件，男人就是低层组件，它的部分行为是由男人定义的（差不多就这个意思，不要太纠结）

那么，究竟是哪里“倒置”了呢，低层组件会依赖高层的抽象，高层组件也依赖相同的抽象
~~（假定男人拥有一个抽象，那么相对于具体实现这个抽象是“高层”的，高层组件也依赖这个抽象）~~
我们一般的思维是从顶端开始，然后往下到具体的类，倒置你的想法就是别从顶端开始，首先想的是甭管什么样的男人都需要一个共同的抽象类，然后人类也会依赖这个抽象类，这样想其实就已经倒置了！大概…..
然后是几个指导方针：

变量不可以持有具体类的引用
不要让类派生自具体类
不要覆盖基类中已经实现的方法

但毕竟是指导作用，不可避免的在某些条件下要违反，只是尽量的遵守罢了；我们实例化字符串的时候都是 new 啊，违反了方针啊，但完全可以，因为字符串不可能改变，所以说要灵活
工厂模式就是这个原则的代表吧

面向对象的五大基本原则

单一职责原则（SRP）
开放封闭原则（OCP）
里氏替换原则（LSP）
依赖倒置原则（DIP）
接口隔离原则（ISP）

OO原则

下面列出了基本的原则：

封装变化
多用组合，少用继承
针对接口编程，不针对实现编程
为交互对象之间的松耦合设计而努力
类应该对修改关闭，对扩展开放
依赖抽象，不依赖具体类
只和“朋友”交谈（减少对象之间的交互）
别找（调用）我，我会找（调用）你
类应该只有一个改变的理由

设计模式一览

这里只是列出了常用的一些模式，并不是全部，每一种模式只是做了简单的解释，具体的实践需要看以前的文章。

策略模式

定义算法族，分别封装起来，让它们之间可以互相替换；此模式让算法的变化独立于使用算法的客户。

比如，提供一些 setter 方法设置相应的“策略”，详细解释：飞机

观察者模式

在对象之间定义一对多依赖，这样一来，当一个对象改变状态，依赖它的对象都会收到通知，并且自动更新。

当有多个观察者时，不要依赖他们的通知次序，因为是不确定的。详细解释：飞机

装饰者模式

动态的将责任附加到对象上；想要扩展功能，装饰者提供有别于继承的另一种选择。

符合开闭原则，在动态代理中应用广泛。
装饰者一般对组件的客户是透明的，装饰者会导致设计中出现许多小对象，过度使用会使系统变的复杂。
通常，我们会在调用真正的原始对象方法之前或者之后做一些动作。详细解释：飞机

工厂模式

工厂方法模式：定义了一个创建对象的接口，但子类决定要实例化的类是哪一个，工厂方法让类把实例化推迟到子类。
抽象工厂模式：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。

我们常用的是简单工厂模式，而工厂方法模式相对复杂一些，另外还有抽象工厂模式；他们都是属于工厂模式。
其中使用到了依赖倒置原则。详细解释：飞机

单例模式

确保一个类只有一个实例，并提供全局访问点。

最广泛的模式之一了吧，考察它的也相当多，写法也比较简单。
不过需要注意多线程并发的问题，懒汉式和饿汉式，使用双重判断的弊端、原子性和一致性，指令重排等，内容还是比较多的。
注意使用多个类加载器也会导致生成多实例。

命令模式

将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。
命令模式也支持可撤销的操作。

让请求调用者和请求接受者解耦，解耦的两者是通过命令对象进行沟通的，封装了其动作。
其中可能会使用“空对象模式”，它可以实现队列请求、日志请求等需求（实现日志系统和事务系统）。
宏命令是一种简单的延伸。详细解释：飞机

适配器&外观模式

将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。

比如 JDK 中的枚举和迭代器？
其中其实还包含有另一个模式：外观模式，它让接口更简单（改变接口的原因），也将客户从组件的子系统解耦。
适配器的意图：“改变”接口符合客户的期望。
外观模式的意图：提供子系统的一个简化接口。

提供了一个统一的接口，用来访问子系统中的一群接口。|外观定义了一个高层接口，让子系统更容易使用。

当需要简化并统一一个很大的接口或者一群复杂的接口时，使用外观。
适配器：将一个对象包装起来以改变其接口。
装饰者：将一个对象包装起来增加新的行为和责任。
外观：将一群对象“包装”起来简化其接口。
详细解释：飞机

模板方法模式

在一个方法中，定义一个算法骨架，而将一些步骤延迟到子类中。
模板方法使子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。

其中可以使用钩子，钩子控制根据某些条件是否执行某部分算法。
还使用了好莱坞原则：别调用我们，我们会调用你。
模板方法可以是一种代码复用的技巧，可以定义具体方法、抽象方法、钩子（可以选择要不要覆盖）。
为了防止子类改变模板方法中的算法，可以定义为 final，并且可以说工厂方法是模板方法的一种特殊版本。
详细解释：飞机

迭代器&组合模式

迭代器：
提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示。
组合：
允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。

他们两个往往能拼在一起使用，使用组合我们能把相同的操作应用在组合和个别对象上（叶子节点），他们通常有（或者提取出）共同的接口，也就是说，在大多数情况下，我们可以忽略对象组合和个别对象之间的差别（只不过有的可能是空实现）。

状态模式

策略模式（主动）和状态模式是双胞胎，在出生时才分开。

允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。

通常，状态模式用类代表状态；Context 会将行为委托给当前的状态对象，状态类可以被多个 Context 实例共享。
同样，使用状态模式通常会导致设计中的类数量大大增加。

代理模式

为另一个对象提供一个替身或占位符以控制对这个对象的访问。
被代理的对象可以是远程的对象（远程代理）、创建开销大的对象（虚拟代理）或需要安全控制的对象（保护代理）。

代理模式要做的主要就是：控制和管理访问，在 AOP 中使用广泛吧。。。
Java 中的 RMI 就是一个典型的例子，远程代理是一般代理模式的一种实现。
虚拟代理：只有当我们真正需要一个对象的时候才创建它，对象创建后代理就会将请求直接委托给对象（显示图片前的“加载中”）。
为了让客户使用代理而不是真正的对象，一般是创建一个工厂，由工厂返回代理对象。
因为实际的代理类是运行时创建的，我们称这个 Java 技术为动态代理。
衍生类还有很多，比如防火墙代理、缓存代理、智能引用代理、同步代理等。
代理在结构上类似装饰者，但是目的不同；装饰者模式是为对象加上行为；而代理是控制访问。
Java 中内置代理支持，代理同样会造成你设计中类的数目增加。

复合模式

符合模式结合两个或以上的模式，组成一个解决方案，解决一再发生的一般性问题。

MVC 是典型的复合模式，其实控制器使用了策略模式（控制器是视图的策略）、模型使用了观察者模式、视图使用了组合模式。
Web 的开发人员对 MVC 进行适配，使它符合 B/S 模型，我们称这样的适配为 Model 2。

其他模式

模式是在某情景（Context）下，针对某问题的某种解决方案。
情景：就是应用某个模式的情况。这应该是会不断出现的情况。
问题：你想在某情景下达到的目标，但也可以是某情景下的约束。
解决方案：就是你所追求的一个通用的设计。

当然你可以改变模式。像设计原则一样，模式不是法律或准则，它只是指导方针，你可以改变模式来符合你的需要。

架构模式
应用模式
三层架构、C/S 系统以及 Web 服务中
桥接模式
不只改变你的实现，也改变你的抽象；会增加复杂度
生成器模式
封装一个产品的构造过程，并允许按步骤构造。隐藏内部表现，产品的实现可以被替换，被用来创建组合结构。
责任链模式
当你想要让一个以上的对象有机会能够处理某个请求的时候，就使用责任链模式。
如果没有任何对象处理它，那它就可能不会被处理。
蝇量模式
如果想要某个类的一个实例能用来提供许多“虚拟实例”，就使用此模式。
解释器模式
中介者模式
使用中介者模式来集中相关对象之间复杂的沟通和控制方式。设计不当，本身会过于复杂
备忘录模式
当你需要让对象返回之前的状态时（比如撤销操作），用于存储状态。
存储和恢复的过程比较耗时，Java 中使用序列化
原型模式
当创建给定类的实例过程很昂贵或者很复杂时，就使用原型模式
访问者模式
当你想要为一个对象的组合增加新的能力，并且封装不重要时

与设计模式相处

保持简单
你的目标应该是简单，而不是如何才能应用上模式；正确的说法是：为了让你的设计简单且有弹性，有时候使用模式是最好的方法。
考虑模式带来的后果
知道何时使用
这更多的是一种经验，要考虑后果，模式往往是在重构中加入的。
找出你设计中会改变的区域，通常这是需要模式的迹象。
利用模式进行重构
比如：你的代码中充满了 if 语句，那么可能需要状态模式；或者意味着工厂模式将这些具体的依赖消除掉。
拿掉不需要的模式
当你的系统变得非常复杂，并且不需要预留任何弹性的时候，就不要使用模式。
现在不需要，就别做
你不确定这一块以后会不会变化就别“过度优化”

有些模式可能并不适合当前的情况，可以对其改编使其适合。
不应急切于使用模式，而是致力于最能解决问题的简单方案。
设计模式也会在你的设计中加入更多的层，这不但增加复杂性，而且效率下降。
并且可以适当了解下反模式（看起来是个好模式，真正采用后就会带来麻烦）