小强所在的游戏公司最近设计了一款赛车游戏，游戏中会有很多种的车型，比如自行车、三轮车、小汽车、卡车、跑车等等。基于面向对象的设计思路，小强设计了一个车的超类，并让各种车辆继承这个超类。因为是新游戏，为了看看市场反响，所以第一版本所有类型的车辆只有样式不同，其他功能都一样：
上线后，用户反响还不错。于是公司决定大力推行这款游戏，设计更多的功能来吸引玩家的加入。于是，小强接到新的任务，除了样式不一样以外，需要让所有的机动车能够加速。这还不简单吗，基于原来的设计，同时兼备代码的可复用性，小强很快开发出了该功能：
父类Vehicle添加了一个accelerate()加速方法，这样所有的车辆就都能进行加速了。同时，为了让自行车等非机动车不能加速，在非机动车相关的子类上都覆盖父类的accelerate()方法，当用户调用该方法时，提示用户该类型车辆不能加速。
功能开发完后，小强很是高兴，这个设计简直是棒极了，机动车类型的车辆都可以直接继承父类的accelerate()方法，避免了许多重复的代码编写，而非机动车类型的车辆只需要覆盖父类的方法就行了，虽然麻烦了点，但是没准以后非机动车也要加速功能呢，可以在这上面改啊，多付出总是没错的……
可是在一次Code Review会议中，开发组组长提出了一个问题：如果以后非机动车越来越多，每新增一个都需要覆盖父类的accelerate()方法是不是太麻烦了。而且，如果以后有更多机动车有而非机动车没有的方法（比如：给车辆加汽油），都按这个设计，添加一个非机动车就需要覆盖一大堆的与自己无关的方法，那真是一场灾难。
看来，这样的设计确实还是存在缺陷。会议结束后，小强思考了一番：上面的问题是因为Vehicle类涵盖了机动车的方法，但是这个方法却不适用于非机动车。那是不是把这些子类对象中，部分有部分没有的方法抽象出来，不放在Vehicle中，而是放在另个一单独的结构中，让各种类型车辆挑选着继承或实现不就行了。
说干就干，小强很快又设计出了一个版本。因为Java不能多重继承，所以，使用接口来放这些方法，子类按需实现即可：
这么设计解决了上面提到的问题，自行车等非机动车不再需要维护一个本不该自己维护的方法，而汽车、卡车等车辆按需继承AccelerateAble接口，在自己的类中实现具体的加速方法。嗯，按需分配，各得其所，就这么搞。
可当小强动手敲代码时就犯起了嘀咕，他发现虽然非机动车不再需要继承accelerate()方法了，可是每一个机动车却需要了。而且因为加速方法的实现都是一样的，却在机动车类型的车辆中各自都要复制一份，代码可复用性太差了。而最最无法接受的是，将来要是要修改这个accelerate()方法，每一个机动车实现类都要修改一遍，这还不如之前的设计呢……
细心的组长发现了正在焦头烂额的小强，再看看他的新设计，笑着说：“其实，你这个新的设计方案虽然不可行，但是已经有一点对的思路了。你能意识到把应用中可能变化的东西提取封装起来，好让其他部分不再受到影响这点很好，可是实现上需要一些改动：如果把accelerate的实现也抽象出来你看怎么样？”。
把实现也抽象出来？那要怎么弄呢？想想看，抽象出来的东西会是这样：
怎么让机动车和非机动车获取到这些实现呢？还是实现AccelerateBehavior接口明显不对，因为接口的具体实现已经有了。不用实现的话，那该怎么办呢？对了！用组合的方式。嗯~is a不行就用has a试试。而基于最开始的设计，由于各类型车辆都继承自Vehicle父类，将AccelerateBehavior作为一个成员变量放入Vehicle类中再好不过了。经过一番折腾，小强终于写出了自己满意的方案：
通过上面的修改，解决了之前遇到的两个问题，非机动车可以不再需要维护自己不需要的accelerate()方法；同时，机动车也可以复用父类给予的机动车加速方法，而具体使用的时候，在构造方法中构建具体的accelerateBehavior属性就可以啦，代码类似这样：
class Bicycle extents Vehicle{ public Bicycle(){ this.accelerateBehavior = new NoAccelerate(); } void style(){ //自行车装饰 }}class Car extents Vehicle{ public Car(){ this.accelerateBehavior = new CarAccelerate(); } void style(){ //小汽车装饰 }}public static void main(){ Vehicle bicycle = new Bicycle(); bicycle.performAccelerate(); Vehicle car = new Car(); car.performAccelerate();}
不知道大家有没有发现，上面的设计还有一个好处就是，以后如果各种车辆的加速方法不一样的话，只需要设计不同的加速方法实现类实现AccelerateBehavior接口，而在具体的车辆构造方法中构造具体的加速属性就可以啦。而且，如果之后还想要搞出一个时而可以加速，时而不能加速的车子（比如小汽车没油了），那么我们可以添加set方法对accelerateBehavior成员变量进行设置，实现动态设置是否可加速。啧啧啧，太棒了！！！
class Car extents Vehicle{ public Car(){ this.accelerateBehavior = new CarAccelerate(); } void style(){ //小汽车装饰 } public void setAcclerateBehavior(AcclearteBehavior acc){ this.acclerateBehavior = acc; }}
拿着最新的设计方案，组长对小强赞许了一番。这个设计：
- 将应用中变化的地方抽取封装出来，不和不变的代码混在一起；
- 针对接口（抽象）编程，代码更易于维护，可扩展性也更好；
- 通过组合而非继承的方式，代码可扩展性更大；
没错，其实上面的这个设计，就是我们要提到的第一个设计模式--策略模式的设计思路：通过抽象封装出算法族，让它们之间可以相互替换，此模式让算法的变化独立于使用算法的用户，用户无需关心算法的具体实现，是要设置好，用就行了。
当然强哥这里只是提了设计的思路，而具体如何使用，如果大家还是一头雾水的话，强哥在今天的第二篇推文中，也转了一篇比较简单易懂的策略模式的具体使用，有兴趣的大家可以看看。
本文编写主要参考自：《Head First设计模式》一书，有兴趣的可以买这本书看看哦，真的是一本极力推荐的书！！！
