HeadFirst设计模式-策略模式-鸭子类的常规实现

概述

策略模式，定义了多个算法类，或者说多个策略类，运行时可以选择任一种算法进行替换。该模式让算法与使用算法的客户解耦，让算法的变化独立于使用算法的客户。

鸭子具体实例

以一个具体的例子说明，我们需要设计一个鸭子类，来描述不同鸭子的不同行为。

按照常规思维，是先定义一个鸭子duck类，具有外形display()和游泳swim()、叫声quack()的行为，然后具体的红头鸭和绿头鸭继承duck类，只需覆盖重写外形display()，游泳和叫声行为不用写代码，就可继承而来。

新增鸭子行为

现在新增一个需求，要求展示鸭子的飞行。

这很好办，在鸭子duck类上增加一个飞行fly()方法，写明具体飞行逻辑。则继承类红头鸭和绿头鸭都具备了飞行方法。

新增鸭子类型

如果我们还需要另外一种类型的鸭子，橡皮鸭子（假鸭子，不会飞也不会叫），则让橡皮鸭子继承鸭子duck类，覆盖重写飞行和叫声类。但是，若再增加一个诱饵鸭（也是假鸭子，不会飞也不会叫），则又需要覆盖重写飞行和叫声类。

后面再不断新增不同的鸭子，还需要不断的覆盖重写，不仅麻烦，还丢失了鸭子间的共性，比如橡皮鸭子和诱饵鸭这两种都是不会飞也不会叫的鸭子。显然，继承并不会解决问题。自然地，想到用接口的方式，设计两个接口，可飞行flyable接口，会叫quackable接口。

接口实现的问题

停下想一下，接口方式会存在哪些问题？平时工作碰见过很多接口，接口总是最佳实践吗？

在这里使用接口，会带来两个问题：

1、改动大，工作量多，每个鸭子类都需重写飞行方法。本来不受影响的红头鸭和绿头鸭都需要重写飞行方法。

2、丢失方法的具体实现。比如飞行接口，每个实现类都需重新编写飞行逻辑，代码重复。

那么，具体使用哪种方式呢，请看下篇《HeadFirst设计模式-策略模式-鸭子类的策略模式实现》。