[学习笔记]设计模式[0]-{策略模式}

设计原则

找出应用中可能需要变化的地方，把它们独立出来，不要和不需要变化的代码混在一起

感觉这个就是整个设计模式的最主要的目标。不用在下个版本的开发的时候去修改上个版本的代码，以增量的形式去增加功能或模块，而不需要去对已有的代码进行修改。这样做的好处首先是在不会因为新版本的bug导致旧版本的功能出问题，而且在写代码的时候思路会更清晰，不用一行一行的去找代码。
实现这个原则需要对项目有很清楚的意识，并且需要有很丰富的经验，能够预料到哪部分的功能在之后会产生变化。也就是书中所说的“面向经验编程”。

针对接口编程，而不是针对实现编程

把可能会发生变化的地方用接口来表示，然后对每种变化用不同的类去实现这个接口。
下面是书中的一个例子：
鸭子类有一个属性是发出声音，可能在第一个版本里只有“呱呱叫”这个方法，但是在之后的版本可能会增加别的类型的鸭子，比如会“吱吱叫”的橡皮鸭，不会叫的玩具鸭。这时候 如果把发出声音这个动作绑定在鸭子类中，就会导致变动代码的不便。
但是如果我们把“发出声音”这个属性定义为一个接口，然后再用不同的类“呱呱叫”、“吱吱叫”去实现这个接口，在声明类的时候去做绑定，这样就可以灵活地增加不同的“鸭子”，也不用担心 新的鸭子会对之前的鸭子产生影响

多用组合，少用继承

“有一个 比 是一个 更好”。
用组合而不是继承的方法，可以更灵活地对对象进行操作。对比以下的两句话：
1.我有两只鸭子，有一个会飞呱呱叫的绿头鸭，和一只不会飞会吱吱叫的橡皮鸭
2.我有两只鸭子，绿头鸭会飞，绿头鸭会呱呱叫，橡皮鸭不会飞，橡皮鸭会吱吱叫。

从中文的表述可以直接对应到类的实现方法。第一种方法是实现一个鸭子的接口里面有飞和叫两个方法，一个绿头鸭继承并实现呱呱叫和会飞的方法，一个橡皮鸭实现并封装吱吱叫和不会飞的方法。第二种方法实现一个鸭子的接口，一个绿头鸭继承并组合会飞这个动作和会呱呱叫这个动作，一个橡皮鸭继承并组合不会飞这个动作和吱吱叫这个动作。

那么问题来了，如果我在下个版本需要增加一个会跳舞的神奇鸭，那么两种实现方式用中文表述就是下面这样：
1.我有三只鸭子，有一个会飞呱呱叫不会跳舞的绿头鸭，和一只不会飞会吱吱叫不会跳舞的橡皮鸭，和一只不会飞不会叫会跳舞的神奇鸭。
2.我有三只鸭子，绿头鸭会飞，绿头鸭会呱呱叫，橡皮鸭不会飞，橡皮鸭会吱吱叫，神奇鸭会跳舞。
从中文的表述就能感觉出来变动的范围和对之前版本的影响了，就不多进行描述了。

设计模式

策略模式

“定义了算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户”。
这句话很难懂，但是不用把这句话记住，只要在需要做一个类似实现鸭子的系统的时候，对别人说：我觉得用策略模式比较好。就可以了。