在wayfarer的文章中提到了如何利用visitor模式实现添加新的功能。如他所说，在实际过程中显的不是那么可爱。不过他为我们提供了一个可行的解决方案，本文将在此基础上使其尽量变的可爱。
Wayfarer所认为的不可爱之处
1、 假设你需要增加新的一种媒体文件，如WMV文件，在既有Visitor模式的架构下，应该怎样？你头疼了，因为实在是太麻烦。你需要定义一个WAV类，继承VedioMedia。最麻烦的是你必须修改VedioVisitor及其所有子类，因为Visit方法中没有包含访问WAV对象的行为。
在visitor模式中，很难对原有的类型（被访问者）进行扩充，这的确是visitor模式的硬伤。
正如wayfarer所说 对于媒体播放器，Vistor模式非但不可爱，而且丑陋。从现实角度考虑，我们要做一个媒体播放器，在设计之初，对于各种媒体应具备的行为，通常能够充分考虑到。且各种媒体的行为是大致相同的。然而对于媒体文件类型，反而是无法估量的。说不定，什么时候又会出现新成果来。从mp3到mp4，再到mpn，你能预知吗？
然而这究竟是我们对visitot模式实现的不够，还是visitot模式本身的问题。
那么让我们来看看添加新的类型，究竟对原来的结构需要做如何的变化。
我们先来看看原有的设计
可以发现在这其中隐藏有“bad smell”，就是每一个的Accept方法是不同的，不同点在于visitor.VisitXXX(this);
这个XXX就是访问的对象类型，对象类型要发生变化，我们当然要隐藏变化，那么这种类型的变化如何隐藏？
通常情况下我们都是隐藏主语的变化，比如visitor的变化我们很容易利用类的多态来实现，那么宾语的变化如何隐藏呢？可以看到该方法有一个参数，而参数的类型就是被访问者的类型，这样我们就可以通过方法的多态来实现类型信息的隐藏。
visitor.Visit(MP3 m);
visitor.Visit(WAV w);
通过函数参数的变化来实现方法的多态，在运行期自动绑定。
在这里提醒大家，不要只记得override可以实现多态，overload也是可以实现多态的。
这样每个类的Accrpt方法就统一了
public override void Accept(AudioVisitor visitor)
{
visitor.Visit(this);
}
既然每个类都同一了那么能否将这个函数提到他们共同的父类当中呢？这也是通常情况下，利用重构来实现的目标，结果非常诱人。
但是，不幸的是――答案是否定的，因为那么一来this的类型信息也就失去了，那么方法级的多态就无法实现了。不过以上的工作还是有意义的，对于简化形式还是起到了帮助，但是由于不能将Accept方法提到父类中，那么意义自然不是太大。
下面将在此修改的基础上我们添加一个类WMA。
在原来的AudioMedia中添加一个类是很容易实现的，也体现了open-close 原则，但是对应的在visitor中的变化，就不那么可爱了。
添加WMA后，vistor部分的代码改变
public interface AudioVisitor
{
void Visit(WMA m );
void Visit(MP3 m );
void Visit(WAV w );
}
public class RenameAudioVistor : AudioVisitor
{
void Visit(WMA m )
{
//do something
}
void Visit(MP3 m )
{
//do something
}
void Visit(WAV w )
{
//do something
}
}
我们需要手工去改写每一个Visitor（抽象的，具体的），在其中添加有关WMA的操作，这严重违反了open-close 原则，这样我们看到了在Visitor模式中实现添加新的类型（在此为媒体类型）是多么丑陋的事，但是这是Visitor模式的问题吗？他能够解决吗？还是我们没有考虑到更好的方法？
如何才能实现在AudioMedia中添加新的类型，使得在Vistor结构中也满足open-close 原则？
不仅仅是违反OCP原则，在添加新类型的时候甚至还要去修改抽象类Audio，而保持抽象不变也是我们所追求的。为什么会这样，究其原因在于在目前的结构下，被访问对象和访问对象互相依赖，自然不利于分离变化，必须去掉一层依赖关系。
下面给出相应的实现方案。
在这里AudioVisitor已经退化到没有任何方法，只是一个空接口供Accept方法使用。
每一个具体类如MP3都有一个对应的Visitor类，在这个类中有Visit方法的声明，也就是说把原来在AudioVisitor中的声明工作，交由各个具体的XXXVisitor接口去完成。这样当添加新类XXX时就添加一个对应的访问接口XXXVisitor，然后在由RenameAudioVisitor实现这些接口，RenameAudioVisitor的工作与前面一样没有什么变化。这样我们就不会去修改AudioVisitor这个抽象类，只要添加相应的访问接口并实现它，部分满足了OCP原则。说是部分那是因为还要去修改RenameAudioVisitor以实现新的接口，但是修改具体类和修改抽象类的代价相比就小的多，使我们面对新的变化也容易的多。
同时还带来了一个好处就是，我们可以有选择的让别人访问。比如MP3不想让别人visit，那么我们不去创建MP3Visitor就是了。
另外注意在Accept方法中有一个转型操作。通过这个操作我们可以进一步保证类型安全，也是通过它我们可以轻易的实现XXXVisitor的选择（即要不要让XXX被访问）。
public override void Accept(AudioVisitor visitor)
{
MP3Visitor mp3Visitor=visitor as MP3Visitor;
if (mp3Visitor!= null)
mp3Visitor.Visit(this);
else //error or there is no Visitor for it
DoNothing（）
}
本文通过对Visitor模式的一系列的调整，让它更容易适应添加新的类型，不知你是否注意到我为Vistor起的名字（RenameAudioVisitor），wayfarer说visitor模式不适合于媒体功能扩展这个应用。这个说法显然不够全面，应该说它不适合扩展诸如Play ，Resize这类的方法。
首先这些基本方法在设计初就应该考虑到，Visitor当然不适合做本来就可以很容易做的事情，其次在wayfarer的例子中没有使用到ObjectStructure, 而这是Visitor模式的一大特点，利用它可以很方便的完成一些任务。所以不是说Visitor不适合媒体功能扩展，而是不适合什么功能的扩展。扩展什么功能进一步决定了采用何种模式。
在接下来的随笔中，我尽可能举一个Visitor模式适合于媒体功能扩展的例子，同时在这个例子中发挥ObjectStructure的作用。另外也想研究一下，Visitor模式可以在哪些实际的场景中发挥作用。
参考资料 《agile software develop》
