四种很相似的设计模式（State，Str…

   
以上四种设计模式其实是很相似的。在我看来：

   
1）State模式和Strategy模式可以视为一样的模式，他们的类图之类都是一模一样的。

   
2）Bridge模式和Strategy模式摆在一起可能让人觉得诧异，因为前者是结构型设计模式，后者是行为型设计模式。但如果不考虑这点。他们就非常相似了：以书中Bridge模式的例子（我记得不清楚了，只能说个大概），draw接口中的函数，有windows的实现版本，也有linux的实现版本。这就是策略模式啊。所以我一直以为Bridge模式和Strategy模式的区别，关键在于用途不同：是否为了构件平台无关的开发基础设施，如果是就是Bridge，否则就是Strategy，可以将Bridge视为Strategy的特例。

   
今天还听到一个观点，就是区别在于是1对多呢（Strategy）还是多对多（Bridge）。Bridge模式的目的是为软件构件一个平台无关的底层。所以肯定不止一个类会使用到这个接口。有点道理，但不完全对。Strategy模式也完全可以多个类使用。所以我还是坚持我的观点，他们的差别在于模式之外，取决于用途。

   
3）关于Visitor。我觉得这是一个很cool又过于花哨导致没啥用的模式哈哈。很多人没有理解对。认为遍历的时候可以OOXX，也可以XXOO就是Visitor模式。那其实是把Visitor模式理解成Strategy模式了。Visitor的关键在于双重分发的机制。所以适用于需要用不同策略来处理不同元素的应用场景。

   
举个例子，某软件有两个皮肤：man和woman，有两种图像种类：大头照和风景。man皮肤会为大头照加上胡子，在风景照中p上坦克。woman皮肤会给大头照加上胭脂，给风景照上p上彩虹。这时候就可以使用Visitor模式了。接口Skin有两个函数void
process(Picture* pic)和void porcess(Photo*
photo)。注意两个函数的名字是完全一样的，这样才能overload。gui需要对某张图像进行处理的时候，只要skin->process(xx)就可以通过双重分发（第二重分发是overload）调用想要的处理流程了。还没完，如果这么实现Visitor，则都必须使用具体Elem的指针/引用去调用process，这样就有点违背面向接口编程了。其实更好的做法是：Elem接口提供一个accept(Skin*
skin)函数，然后Picture/Photo类在此函数中调用skin->process(this)。则gui调用
xxx->accept(skin)也通过双重分发机制（第二重分发还是多态，采用此实现时process函数名可以不一样，因为不需要overload）调用想要的处理流程了。

   
双重分发（override+overload or
override+override，建议用后者），visitor模式很有特色。但能用来解决啥问题呢？貌似所有有多种Elem的地方都可以使用到该模式。但仔细分析，除了类爆炸和华丽外,似乎Visitor模式没带来啥东西了。

   
ps:对Visitor的评介可能不公平不正确。只能说目前我还没见过适合使用Visitor模式的场景。