Head First设计模式学习（一）策略模式

计划

学习一件事物之前，先想清楚再开始最好，学习计划如下：

时限：两个月（10月31日 —— 1月1日元旦假期前）
总量：13 chapters
平均时速：1 chapter/week
规律任务：每周写一篇对应章节高质量博文

学习要点：

• 不要只局限于此书，需要从互联网和别的地方寻找任何你感到疑惑的地方并解决，例如配合refactoring
• 时限意味着需要在时限内学完，就是没有任何疑问和不理解的地方，这意味着你会不只读一遍
• 掌握的意义（需要你在每一篇博文下面回答这些问题）：
  • 你可以回答出以下问题
    • 为什么存在？
    • 这个项目应用了什么设计模式？你认为真的合适吗？有更好的模式吗？
    • 你可以使用它独立的写出一个程序，无论大小，请展示出来？
  • 更高的级别
    • 你能混合各种模式进行开发吗？
    • 你能设计自己的模式吗？

---

策略模式

软件开发完成 “前” 以及完成 “后”，何者需要花费更多时间呢？

作为一个最初级的模式，策略模式可以帮我们解决应用程序的后续扩展性和可维护性的问题；

核心思想

从抽象出的所有方法中提取出变化的部分，将其更加抽象

例子：

现在我们要做一个模拟鸭子游戏，这个游戏会有各种各样的鸭子，此系统使用了标准的OO技术，设计了一个鸭子超类，也就是超级父类Duck，所有的鸭子都会继承这个类，和里面的方法，并根据自己的需要重写方法；

目前就是这个样子；看得出来只要有新鸭子出来，只要继承Duck就能获得鸭子的所有功能，有啥区别再改写就行了；

但是废话少说，有什么缺陷呢？？

这个时候公司让你新增加一些鸭子，并且这些玩意儿得会飞（ fly（）），然后你直接在Duck里加了一个fly，不然还能怎样呢？

然后你发现橡皮鸭子也跟着飞起来了，因为这玩意儿也继承了Duck；

这说明什么，说明fly这个动作他不是不变的，也就是说不是全体共有的属性，那么看看上面说的话，我们就要把它继续抽象出来；

你说非得抽象出来吗？我说是的，不然也行，你就把fly放到Duck里，然后每写一个xxxxDuck，你都要重写这个方法；你愿意过这种生活吗？

然后你把 flyable 变成了一个接口，谁用谁实现

你以为这样就行了吗？这跟刚才本质上没啥变化吧，，

你自己用就你自己实现，别人就算跟你功能一样也不能用你的，明显会导致重复代码变多，因为 interface 不能实现方法；

也就是说，我们不仅要把变化的东西抽象出来，还得保证代码的复用性；

那刚才是什么导致了复用性下降呢？就是 interface 不能实现方法，那什么能实现方法呢？那就是 interface 的implement能实现方法；也就是说，我们要把 flyable 抽象到 interface 的implement上；

众所周知，interface 可以有无限多的实现，但是各种implement类都可以用 interface 的类型来接收【上转型】；

也就是说，一个固定的 interface 类型成员，可以接收很多种类的 implement，这就可以复用了嘛；

我们直接在Duck里设置一个Flyable接口成员，然后让它去调自己的fly方法，而这个fly方法具体是什么，由你给它初始化的implement决定

吆西，挺好

你看，虽然 flyable 有很多种实现方法，但是在Duck里只用写一个接口，具体接什么由子类初始化决定，而且这些实现都可以复用；

这种关系叫：组合

但是还不够，因为我们在构造器里制造了一个实现类的实例

不过目前已经够用了，这个问题我们在接下来的设计模式中会继续探索；