读书笔记：Head First设计模式第一章：策略模式

设计模式，顾名思义就是设计的时候可以有一种通用的模式，通用的解决方案。为什么是通用的，因为所解决的问题是类似的。换句话说，是前人们在遇到某类问题后，整理出来，经过时间检验的，较好的解决方案。

问题虽然是类似的，但是不一定一样，通用的解决方案，并不是说一定这样做，需要把握其思想原则，进行变通。通俗的说就是，对于这类问题，管它千变万化，大体的解决思路不变。

 

第一个设计原则：

找出应用中，可能变化的地方，将其独立出来，避免和不需要变化的地方混在一起。

我们通过书中的场景来说明这个原则。现在有一款模拟鸭子的游戏，游戏中有各种鸭子。所有的鸭子都会呱呱叫和游泳，但是鸭子的外观不一样，有绿头的，红头的。

这个时候，我们会把公共的行为放在基类中，而不同的，放在子类中，这个没什么问题。但是现在来了一个新需求，让这些鸭子可以飞起来。飞这个行为并不是所有鸭子都有的，比如说橡皮鸭？所以这个行为是不能放到基类中，但是也不能放到子类中，无论是哪种，都会导致有多少个会飞的子类，就要写多少遍。放在基类中你要在子类覆盖，放在子类中你就要自己写。

一旦出现重复性的工作，肯定需要优化。继承的路走不通了，如果是我的话，我会将会变化的行为提出来，变成一个接口，比如说书中提到的FlyBehavior，QuackBehavior接口，然后用抽象类实现接口，提供默认的方法，比如说搞个会飞的抽象类，搞个不会飞的抽象类，想用哪个就用哪个。

接下来我会想，这些是否可以继承，多继承嘛不支持，那就单继承：

鸭子{
    游泳
    外观
}

会飞的鸭子 extend 鸭子  implements FlyBehavior{
    
}

不会飞的鸭子 extend 鸭子 implements FlyBehavior{
    
}

吱吱叫的鸭子 extend 鸭子 implements QuackBehavior{
    
}

呱呱叫的鸭子 extend 鸭子 implements QuackBehavior{
    
}

这样看起来是不是很奇怪，那如果又想要呱呱叫，又想要飞，那咋办，所以还是只能声明为鸭子的属性，也就是组合在一起：

鸭子{
    飞的行为
    叫的行为
    游泳
    外观
}

现在你要什么行为就组合说明行为，是不是和方便，所以组合的好处体现出来了，它可以隔离变化，可以看到鸭子类已经和这些具体的行为无关了，减低解耦程度，增加弹性。而且分离的这部分代码是可以复用的，换句话说，一旦有新的行为出现，我们可以不用修改原有的代码，不会影响到鸭子这个基类，也不会影响行为类。

需要注意的是，为了达到这个目的，不一定要用接口，你也可以用抽象类，只要可以让声明类不用理会执行的对象是什么就可以。所以常说的针对接口编程，不仅仅指的是java中的interface。

这里也说到了第二个设计原则：

多用组合，少用继承

继承有时候限制还是相当大的，通过上面的场景，我们引入了第一个设计模式，策略模式：

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

这里的算法就是之前说到的行为，行为可能各不相同，比如说你这个鸭子会飞，那个鸭子不会飞，但是基类用的是接口，具体是不是会飞，它并不关心。

 

我想到一个例子，比如说键盘，按键就这些，但是通过改键，这些按键可以表达的东西不一样，是不是也算是一种策略的替换？

比如说过滤链上的过滤器，某个请求要经过多次的过滤，链上都有上面类型的过滤器不需要知道，只要每次都filter，返回一个结果，是被拦截了，还是通过了，就可以了。

再比如说，第三方的库封装，客户在使用的时候可能接口调用一直保持不变，变的只是接口里面的实现。调用无感知。同理请求也是，请求的接口可以一直不变，但是里面的实现，处理的策略可以一直的迭代优化不是？

给人感觉就是一个黑盒子，我提供接口，你给我对应接口的实现就可以，比如说插座，你可以插上电脑，电视机，排插等等，无论是什么，只要是对应的就可以。那可能会问题，对不上怎么办，就找个转换口，比如说usb插头，这个就是适配器了，也就是适配器模式，后面会回顾到。

 

注：笔记嘛，就是写自己的理解和思考的过程，结合书里面的内容。这本书我之前看过一遍，有点忘了，再来回顾一下。