设计模式阅读笔记（1）--------策略模式

最近在阅读设计模式的书，随手做一些笔记供将来复习之用。在看书之前就从其他人口中得知，设计模式的学习，并不是来强迫自己使用这些模式，而是要依据实际情况而定，有时候也并不一定要使用。而我们对设计模式的学习，也不是要强迫自己把所有的模式都记在脑中，其实手中留有一本书当做工具书，使用的时候再去查阅也是很好的。

设计模式是前人经验的一些总结，是遵循OO设计思想的各方面体现。按我看到现在来想，总的来说，就是要保证程序可扩展性的同时，还要封闭程序一些地方避免修改。可扩展是为了程序维护的方便，而封闭是因为已经正常运转的部门就应该留下，为了复用考虑。

第一个学习的策略模式，策略模式的总结是将算法和行为封装起来，使之间可以替换，当我们修改算法和行为的时候，对使用算法和行为的类可以不用变动。

当我们设计类的时候可能会用如下设计：

这样看起来相当正常，猫、狗、牛都继承了动物类，并且都具备叫声和跑步的行为，这样，子类复用到了父类的代码，也可以覆盖具有自己独特的叫声行为。但是当我们变更需求，需要加入老鹰这个类呢？问题出现了，老鹰也是种动物，应该继承动物类，而且老鹰也可以发出叫声，但是老鹰可不会跑步啊。但是并不是没有解决办法，将老鹰类中的跑步方法覆盖，变成什么都不做就行了。在加入鱼类呢，鱼既不会有叫声也不会跑步，我们又需要将鱼类中的跑步和叫声都覆盖成什么都不做。也就是说，每个类都要考虑他们的行为有什么不同，如果和父类有差别就要在子类覆盖。

还有这种设计方式：

这样看来似乎是可以通过实现接口与否解决新增的类能不能跑步或有没有叫声，但是却导致情况更加了复杂，每一个子类都要自己实现跑步和叫声接口！这样根本不能达到复用的目的。

这时候我们应该考虑到这样一个设计原则：应该讲代码中经常变化的地方独立于不会修改的地方。也就是说，动物的行为是多变的，应该把这部分行为独立出来，而保留不会修改的地方，比如呼吸方法，每个动物都会呼吸。如果将行为独立出来？我们可以想到将行为抽出委托给其他类来执行。同时，我们要针对接口编程而不是针对实现编程。

根据这些情况，我们可以做出如下设计：

从图中看出，我们将动物的行为抽取出来，设计了运动接口和发声接口，在动物类中，存放了两个属性与接口联系，在动物类中，行为方法变成了执行运动和执行发声，在方法中，并不具体实现，而是调用接口的相应方法。对于运动接口和发声接口，我们可以用多种的实现类。这样，当新的动物子类进入时，我们可以编写相应的运动实现类和发声实现类。给动物子类设定相应属性后就可以让动物子类拥有不同的行为了，设置可以在运行时动态的决定。