设计模式学习笔记—策略模式

最近在看《Head First 设计模式》。收获蛮多的，所以也写一写自己的收获和感悟。

首先，什么是设计模式。我觉得设计模式可以理解为套路。模式不是代码，而是针对设计问题的通用解决方案。在不同的需求，不同的要求下，我们怎么来设计我们的类，怎么来安排类与类之间的关系，从设计模式中，我们能够得到很好的启发。可以说设计模式能够帮助我们将应用组织成容易理解，容易维护，具有弹性的框架。学习设计模式，也就是在学习其他开发人员的智慧与经验。

这几天了解了第一个模式——策略模式：定义了算法族，分别封装起来，让它们之间相互替换，此模式让算法的变化独立于使用算法的客户。

也就是一个类的行为被封装进了一组类中，可以被轻易的扩充与改变，如果需要，甚至可以在运行的时候也可以改变行为。

如果单看这个定义，很难明白，所以我们来看一下几个设计原则：

l 找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。

这个其实很好理解，首先，我们都知道在软件开发过程中往往会遇到这样的事就是——改变，修改代码。随着需求的变化，技术的改变，数据更新等等，我们都往往需要去改变代码，如果设计的不好，往往会很悲惨。所以如何让我们现在写的代码，在之后的时间里也能够用的上，这个原则就很重要。

这个原则也可以理解为，把会变化的部分，单独取出来并封装起来，好让之后进行扩充，改变，却不影响其他不需要改变的部分。这也就减少了很多的工作量。我们的代码也并的更加有弹性。

比如说游戏的角色类需要一个飞行的行为，但是每一角色的飞行动作都不一样，而且也不是所有的角色都一开始就会飞。所以飞行的行为就是一个改变的行为。我们把它分离出来然后进行封装。封装的方法就是，把会改变的行为定义成接口，然后再定义专门的类来实现它。

l 第二个原则就是针对接口编程，而不是针对实现编程。

针对接口编程也就是针对超类型编程——变量的申明类型应该是超类型，通常是一个抽象类型或者说是一个接口，这样做的一个好处是我们可以在运行的时候改变调用的对象。对于这个原则，我们可以理解为，当A类拥有一个B超类（为接口或者说抽象类）时，A就可以调用所有实现了B类的类所产生的对象，所以说我们在运行的时候可以改变调用的对象（可以变成B的子类）。

其实这个原则在JAVA的很多地方都可以看到：

比如说JTree

我们来看一下他的部分源代码：

public class JTree extends JComponent implements Scrollable, Accessible
{/*** The model that defines the tree displayed by this object.*/transient protected TreeModel        treeModel;/*** Models the set of selected nodes in this tree.*/transient protected TreeSelectionModel selectionModel;/*** The cell used to draw nodes. If <code>null</code>, the UI uses a default* <code>cellRenderer</code>.*/transient protected TreeCellRenderer  cellRenderer;

无论是JTree，JList还是JComboBox，他们都有类似的属性，model以及render，也就是模型以及渲染器。

在上面的JTree中的三个属性， treeModel，selectionModel以及cellRenderer分别是TreeModel,TreeSelectionModel,TreeCellRenderer的对象，而他们都是接口。在java中也提供了实现了这个接口的类，例如：TreeModel有DefaultTreeModel。TreeCellRenderer 有DefaultTreeCellRenderer。

在创建的时候，我们需要去实现一个子类来赋给treeModel这个对象，这个类可以是java默认的，也可以是我们自己写的。

“针对接口编程”，关键就是利用了多态， 程序针对超类型编程，执行时会根据实际实际状况执行到真正的行为，不会被绑死在超类型的行为上。

l 第三个原则：多用组合，少用继承

理由： 使用组合建立的系统具有很大的弹性，不仅可将算法组封装成类，更可以“运算的时动态改变行为”，只要组合的行为对象符合接口的标准即可。

所以，类与类之间的关系，“有一个”可能比“是一个”更好。