.Net中的设计模式——Visitor模式的可行与不可爱

可否使用Visitor模式实现系列二的例子呢？经过我的悉心研究，结论是Visitor模式对于本例而言，可行但不可爱！

我们先看看本例最初的类图：

我们可以将这个类图看作是一个树形结构。那么各个类即可以看作是树的枝叶节点了。这样一说，似乎和Composite模式有些关系了。其实不然，因为我所谓的树枝节点，如AudioMedia类，与MP3及WAV类并非是聚合的关系。认识到这一点很重要，为避免混淆视听，我将这些类只称作节点好了，就别提树枝树叶，避免产生误会。

而Play()以及Resize()方法，就可以认为是这些节点共同的行为，然而其行为的内涵则是不相同的。也就是说，RM和MPEG虽然都有Play()方法，但Play的操作不同。也就是说，现在，我们可能会为这些不同的媒体类型不断提供更多的行为。而Visitor模式呢？其优势就在于：
为各节点增加新的行为，变得非常的容易。

也就是说，Visitor模式对于本例而言，是可行的。但这破坏了一个前提，就是如果适用Visitor模式必须要更改原来的设计架构，除非你愿意再为这些媒体类分别进行Wrap！好吧，既然是出于研究目的，我们就来看看Visitor模式的应用。修改前提为：重构原来的设计，使旧有的媒体播放器，能够非常容易地扩充行为。

使用Visitor模式，最大的特点是将被访问对象（通常称为节点或元素）的行为，与其对象分离。并用专门的Visitor对象，管理节点的行为。在本例中，抽象节点包括：AudioMedia和VedioMedia。其下的具体节点分别为：MP3、WAV和RM、MPEG。那么在Vistor对象，就应该包括四个访问行为。

是这样吗？看来还有些问题。从实际需求来分析，本例的节点应分为两大类型：视频媒体和音频媒体。而这两类媒体的行为方法，可能是不相同的。例如，视频媒体除了要求Play()方法外，可能还需要Resize()方法。而音频媒体就没有必要使用Resize()方法了，反而会需要视频媒体不需要的方法ShowScript()。因此结论是：我们应该分别为AudioMedia和VedioMedia建立不同的抽象Visitor类。最后获得应用Visitor模式的类图如下：

其实此时IMedia接口已经可以去掉，我之所以保留出于两个目的：
1、为两种类型媒体保持类型的抽象；
2、可以提供两种类型媒体同时具有，且不需要Visitor的行为；
（注：此时的Play方法其实可以放到IMedia接口中。我仍然将其放到Visitor的目的是，便于说明Visitor模式，同时通过这种方式，使对Play方法的修改较为容易）

请大家注意上图的类图左侧，即我定义的媒体类型对象区，在这种Visitor模式设计的前提下，对于类型的行为来说，是非常稳定的。即：无论你要为这四种媒体类型增加什么行为，都不需要修改该区域的任何类或接口；而你只需要在Visitor下增加行为的具体Visitor类即可。这就符合了OO思想中非常著名的开—闭原则。左区即为相对的闭区间（我不能说是绝对的对修改关闭，因此，我才用虚线来作界定），而右区则为相对的开区间。

还是来看看源代码：
首先是被访问的类型：
public interface IMedia
{}

public abstract class AudioMedia,IMedia
{
 public abstract void Accept(AudioVisitor visitor);
}

public class MP3:AudioMedia
{
 public override void Accept(AudioVisitor visitor)
 {
  visitor.VisitMP3();
 }
}

public class WAV:AudioMedia
{
 public override void Accept(AudioVisitor visitor)
 {
  visitor.VisitWAV();
 }
}

public abstract class VedioMedia,IMedia
{
 public abstract void Accept(VedioVisitor visitor);
}

public class RM:VedioMedia
{
 public override void Accept(VedioVisitor visitor)
 {
  visitor.VisitRM();
 }
}

public class MPEG:VedioMedia
{
 public override void Accept(VedioVisitor visitor)
 {
  visitor.VisitMPEG();
 }
}

请注意，在我的Visitor方法中，并没有将节点或元素对象传递给Visitor。这一点，与通常的Visitor模式实现小有区别。

下面是Visitor的实现：
public abstract class AudioVisitor
{
 public abstract void VisitMP3();
 public abstract void VisitWAV();
}

public class PlayAudioVisitor:AudioVisitor
{
 public override void VisitMP3()
 {
  //实现MP3的Play方法；
 }

 public override void VisitWAV()
 {
  //实现WAV的Play方法；
 }
}

public class ShowScriptAudioVisitor:AudioVisitor
{
 public override void VisitMP3()
 {
  //实现MP3的ShowScript方法；
 }

 public override void VisitWAV()
 {
  //实现WAV的ShowScript方法；
 }
}

public abstract class VedioVisitor
{
 public abstract void VisitRM();
 public abstract void VisitMPEG();
}

public class PlayVedioVisitor:VedioVisitor
{
 public override void VisitRM()
 {
  //实现RM的Play方法；
 }

 public override void VisitMPEG()
 {
  //实现MPEG的Play方法；
 }
}

public class ResizeVedioVisitor:VedioVisitor
{
 public override void VisitRM()
 {
  //实现RM的ShowScript方法；
 }

 public override void VisitMPEG()
 {
  //实现MPEG的ShowScript方法；
 }
}

现在我解释一下为什么不在Visitor方法中传递节点对象。从上面的Visitor实现，可以看到。每个Visitor的Visit方法，实际上代表的就是各自的行为，或者是Play，或者是Resize，等等。而这些行为均是在Visitor中实现的，而非它访问的节点对象。也就是说，通过Visitor模式，我将各个媒体对象的行为都交给Visitor了。既然干活的对象发生了转移，那么发生了什么责任，也就去找Visitor吧，这个责任可与媒体对象本身没有关系了啊。

根据Visitor模式，一般还应该提供结构对象(ObjectStructure)角色。然而我在开篇名义之处，就提到本例中，媒体类型对象是不存在聚合关系的，因此不需要劳烦ObjectStructure来枚举每个节点了。也许，这个Visitor模式有些不伦不类吧，没关系，我们只需要了解这个模式的思想。

现在看看客户端的调用：
public class Client
{
 public static void Main()
 {
  //调用视频媒体的Play方法；
  VedioMedia rm = new RM();
  rm.Accept(new PlayVedioVisitor());

  //调用音频媒体的ShowScript方法；
  AudioMedia mp3 = new MP3();
  mp3.Accept(new ShowScriptAudioVisitor());  
 }
}

从上面的Visitor实现可以看到，每个Visitor的Visit方法，实际上代表的就是各自的行为，或者是Play，或者是Resize，等等。而这些行为均是在Visitor中实现的，而非它访问的节点对象。也就是说，通过Visitor模式，我将各个媒体对象的行为都交给Visitor了。既然干活的对象发生了转移，那么发生了什么责任，也就去找Visitor吧，这个责任可与媒体对象本身没有关系了哦。

如果要添加行为，那么同样把责任交给Visitor吧。为该行为定义一个Visitor类，继承抽象Visitor类即可。看看被访问对象，因为Visit方法接受的是抽象Visitor类对象，Accept()方法对于各种行为是完全一致的，你自然不需要修改媒体对象区间的这些所有对象了。这也是Visitor模式最有价值的体现。例如，我想为视频媒体增加一个行为Brighten()，该行为能够让画面更亮。

首先定义一个Brighten的Visitor类：
public class BrightenVedioVisitor:VedioVistor
{
 public void VisitRM(RM rm)
 {
  //增加亮度的方法实现；
 }
 
 public void VisitMPEG(MPEG mpeg)
 {
  //增加亮度的方法实现；
 }
}

我们来看看，不改变视频媒体类的任何代码，能否调用Brighten方法？对了，很简单：
rm.Accept(new BrightenVedioVisitor());

看了上面的描述，也许你会认为Visitor模式不仅是可行的，而且真的很可爱呢。但我却要说它是不可爱的，至少针对本例是如此。请设想这样几种情形：
1、 假设你需要增加新的一种媒体文件，如WMV文件，在既有Visitor模式的架构下，应该怎样？你头疼了，因为实在是太麻烦。你需要定义一个WAV类，继承VedioMedia。最麻烦的是你必须修改VedioVisitor及其所有子类，因为Visit方法中没有包含访问WAV对象的行为。
2、 当各种的对象的行为越来越多时，怎么办？你需要为每种行为都创建一个Visitor。例如我希望提供加亮的同时，还能提供变暗的功能，是不是又要为其建立Visitor对象呢？假如这些行为所属的Visitor对象之间，又没有什么聚合的关系，即无法引入ObjectStructure来管理，你一定会烦不胜烦的。
3、 当各种对象行为的外部接口非常复杂时，例如传递复杂的对象，甚至可能会有out或ref参数，同时还有返回对象，又该怎么办？你一定注意到了，所有的Visit方法所代表的行为都没有返回值，也没有传递参数。如果真要解决，你恐怕只有为被访问对象引入属性了。这不又要修改被访问对象吗？

明白它的不可爱之处了吧。那么Vistor模式的优势又在哪里呢？上面其实已经不厌其烦地说过多次，那就是在保证被访问对象相对稳定的情况下，为现有系统添加行为带来了便宜。

尤其我要说，对于媒体播放器，Vistor模式非但不可爱，而且丑陋。从现实角度考虑，我们要做一个媒体播放器，在设计之初，对于各种媒体应具备的行为，通常能够充分考虑到。且各种媒体的行为是大致相同的。然而对于媒体文件类型，反而是无法估量的。说不定，什么时候又会出现新成果来。从mp3到mp4，再到mpn，你能预知吗？所以，根据本例而言，你是在利用Visitor的劣势了。

为什么还要写本文？是因为我想告诉你两点：
1、 Visitor模式的优势与劣势；
2、 通过一个反面教材，有时候比正面教材给人印象更深；

让Visitor模式用到它最擅长的地方吧。让它不仅可行，而且还要可爱！