用策略模式设计车子模型

本文主要是介绍用策略模式设计车子模型，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

小强所在的游戏公司最近设计了一款赛车游戏，游戏中会有很多种的车型，比如自行车、三轮车、小汽车、卡车、跑车等等。基于面向对象的设计思路，小强设计了一个车的超类，并让各种车辆继承这个超类。因为是新游戏，为了看看市场反响，所以第一版本所有类型的车辆只有样式不同，其他功能都一样：

上线后，用户反响还不错。于是公司决定大力推行这款游戏，设计更多的功能来吸引玩家的加入。于是，小强接到新的任务，除了样式不一样以外，需要让所有的机动车能够加速。这还不简单吗，基于原来的设计，同时兼备代码的可复用性，小强很快开发出了该功能：

父类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;}
}

拿着最新的设计方案，组长对小强赞许了一番。这个设计：