设计模式之小题大作：Command/Strategy/Visitor
要实现一个树的遍历。这本来是一件很简单的事。定义一个访问函数，如，C++版本：
bool visit(TreeNode<T> * pNode);
或Java版本，可以定义一个Visitor接口，
interface TreeNodeVisitor {
public boolean visit(TreeNode node);
}
然后在traverse()方法中带上这个接口的实现就可以了吧。
但如果我一定要把这个问题复杂化，小题大作的用一下设计模式来做，那又应该如何呢？
我首先想到的就是visitor模式。事实上这个工作的名称的确是visit，那相应的类是Visitor也就
顺理成章。然而visitor模式的目标是为了给一个对象结构加入一些新花样，我这里没有什么花样可加，
用visitor模式就不是那么理直气壮了。
接下来我想到command模式。我这样弄不就是给树节点送上一个命令，让这个命令去操作它吗？又假设
我还有其他操作想一一来用于遍历树的各个节点，命令好象能派上用场。
再看命令模式的“适应性”第一条：命令模式是代替回调函数的面向对象实现。
不过命令模式还有其他更强大的功能，比如命令的排队、记录、事务、取消等。这样一来就有点大材小用了。
在GoF的代码实现在，还给出了一种简单命令实现，通过模板类，对不需要取消、也不需参数的命令进行实现。
这个和我的需求很接近了。
策略模式。
策略模式是用于封装大量有共同接口的算法实现的模式。在《大话模式》中举的例子是商场搞打折之类的东西，
如果我把对树进行遍历时做的操作看成是很复杂的算法实现，用策略模式来做也未尝不可。而且策略模式本身
只是处理算法的封装，没有什么事务、排队、取消等东西，纯粹得多。
结论：
设计模式是很灵活的，相互之间会有一定的适用性重叠。在选择设计模式的时候，只需要关注自己要达到的目标，
然后选择合适的模式来做即可。而有时，设计模式可能只是一个名称，一种建议。 如果是数据结构和算法，我觉得还是用传统的面对过程的方式去做，因为效率高。对遍历，树，递归，之类的算法来说，基本类型比对象更节约内存，效率更高，速度更快。这些算法完成后封装成类，再用OO的方式被调用，更合适。算法这样的粒度，对设计模式来说，还是太细了点，按你标题来说，是有点小题大作了。
页:
[1]