第五章 代码的可复用性——可复用的设计模式
这一部分主要分两个方面：结构型模式、行为类模式来介绍六种java设计模式：
前三种为结构型模式，后三种为行为类模式
1. 适配器模式（Adapter）
该设计模式的目的在于将某各类/接口转换成客户期望的其他形式。
其核心思想是通过增加一个接口，将已存在的子类封装起来，客户端面向接口编程，从而隐藏了具体子类。并提供给一个用户希望得到的接口。
其用现有的各种组件组合成一个新的系统（包装wrapper）
首先我们来看一下适配器模式下的栗子：
类图：
如果我们不采用适配器模式会如何？
可见，客户的期望与此是不符的。
那么我们采用适配器模式：
这样，客户的需求就满足啦，也不必重新编写代码了。perfect！
2. 装饰器模式（Decorator）
允许向一个现有的对象添加新的功能，同时又不改变其结构。装饰者可以在所委托被装饰者的行为之前或之后加上自己的行为，以达到特定的目的。
该设计模式要解决的问题是为对象增加不同侧面的特性。
核心思想：对每一个特性构造子类，通过委派机制增加到对象上。
类图说明：
一点理解：就是假设有ABC三个对象分别拥有不同的特性，那么我们现有一个对象A（具体装饰类），想为其添加BC对象（具体组件）中的特性，如何办呢？我们可以去创建一个我们想要的期望对象的一个接口（抽象装饰类），至于如何实现其中的方法我们先不急。先在来构建一个引用BC的抽象类（抽象组件），那么好了抽象组件拥有BC的所有功能，A（具体装饰类）拥有A的所有功能，我们需要的是可以拥有这些功能的抽象装饰类（接口），接口里面实现的功能就都有了。那么我们只需要根据实际情况将抽象组件与具体装饰类通过委派等关系串在一起就实现了嘛……
这里大家如果不懂可以看这篇博客上的栗子，虽然没有写如何为具体类装饰方法，但思想很清晰，很容易理解，装饰方法大家可以自己尝试，思想有了不是很难。
3.外观模式（Facade）：
其想要解决的问题是：客户端需要通过一个简化的接口来访问复杂系统内的功能如何做？
核心思想：通过一个统一的接口来取代一系列小接口调用，相当于对复杂的系统做了一个封装，简化客户端的使用。
类图：
这个模式是我认为这三个模式中最简单的，看个栗子吧：
传说中的外观模式！
客户端使用：
不知道看完这个例子的你是什么感受，反正当时我的感受是，纳尼？这不是我为了少写点代码才干的事情么？把方法里面的ifelse语句换成成了枚举类switch一下就成外观模式了？坑爹呢啊！！
其实就是等价的几种情况整合了一下，抽出来个枚举类，然后代码外用枚举类中的元素表示需求，代码内用一堆switch去判断实现，干货觉得是最少的了……
4. 策略模式（Strategy）：
啦啦啦第一个行为类模式，也是我最喜欢用的一个，真心好用……
其需要解决的问题是：针对特定任务存在不同的算法，但客户端可以根据动态上下文在运行时切换算法。
核心思想：创建一个接口，并为算法中每一个变体创建一个实现类。
类图：
具体例子大家可以看这篇博客，写的很形象生动，如果大家觉得太长想要总结可以看下面我的一些理解。
看起来很复杂，其实你只需要构建两种类一个接口就够了，首先清楚你要做什么，把这些算法抽象为一个接口作为抽象策略类。然后就是分别用算法ABCDEFG去实现这些接口啦，现在你基本已经完成了所有动脑思考的问题。最后一步建立环境策略类，还记得上节讲的组合（composition）嘛？就是用这种委派方式，将抽象策略作为环境策略的一部分（成员变量，放在构造方法初始化）最后用户需要什么方法就在这个类中建什么方法至于实现？接口不都实现好了么？直接委派，暴力I love！（提一句，这里作为成员变量有点桥接模式【代码可维护性设计模式】的意味，其实策略模式是可以修改策略的，比如在环境决策类建立变值器修改该成员变量）
之所以喜欢这个模式就是因为都是模式化的东西，算法ABCDEFG实现肯定是已经存在的东西（当然实现起来很掉头发），需要做的就是抽象接口，和一个一点都不用脑子的环境策略类。一直在工作却不需要用脑子还没有罪恶感最棒了OwO……
5. 模板模式（template）
其要解决的问题是：几个客户共享相同的算法，但具体细节不同，即算法由可定制的部分和不变的部分组成。 常见的步骤不应该在子类中重复，但需要重新使用。说白了就是做事情的流程一样，但是方法的各个实现有可能不同。
核心思想：共性的步骤在抽象类内公共实现，差异化的步骤在各个子类实现。（使用继承和重写来实现）
类图：
这个也是简单又很实用的设计模式，现在来看个例子就理解个大概了：
抽象类：
此处注意这个processOrder方法！此处流程是固定的！
具体子类（一个就够了，这都不重要）：
客户端代码：
怎么样？是不是也是一个简单暴力的设计模式？然而这个固定流程真是……唉！（加粗是提示一定要记住这是有条件的！）
6.迭代器模式（Iteractor）
其解决的问题是：客户需要统一的策略来访问容器中的所有元素，与容器类型无关 。
解决方案：迭代器策略模式
类图：
栗子：
思想和行为都很直接，但是觉得没怎么用过==！而且这不就是自定义一个迭代器嘛，没咋用过没有经验深度理解不敢说不敢说……0.0