《让僵冷的翅膀飞起来》系列之四——Visitor模式之可行与不可爱

Idior一再说,对于系列二的例子,使用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的行为;例如下面我就为媒体类型提供了都具备的方法:OpenFile()和CloseFile();
(注:此时的Play方法其实可以放到IMedia接口中。我仍然将其放到Visitor的目的是,便于说明Visitor模式,同时通过这种方式,使对Play方法的修改较为容易)

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

还是来看看源代码:
首先是被访问的类型:
public interface IMedia
{
   void OpenFile();
   void CloseFile();
}

public abstract class AudioMedia,IMedia
{
 public void OpenFile()
 {
    //打开媒体文件;
 }
 
 public void CloseFile()
 {
    //关闭媒体文件;
 }
 public abstract void Accept(AudioVisitor visitor);
}

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

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

public abstract class VedioMedia,IMedia
{
 public void OpenFile()
 {
    //打开媒体文件;
 }
 
 public void CloseFile()
 {
    //关闭媒体文件;
 }
 public abstract void Accept(VedioVisitor visitor);
}

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

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

下面是Visitor的实现:
public abstract class AudioVisitor
{
 public abstract void VisitMP3(MP3 mp3);
 public abstract void VisitWAV(WAV wav);
}

public class PlayAudioVisitor:AudioVisitor
{
 public override void VisitMP3(MP3 mp3)
 {
  mp3.OpenFile();
  //实现MP3的Play方法;
  mp3.CloseFile();
 }

 public override void VisitWAV(WAV wav)
 {
  wav.OpenFile();
  //实现WAV的Play方法;
  wav.CloseFile();
 }
}

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

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

public abstract class VedioVisitor
{
 public abstract void VisitRM(RM rm);
 public abstract void VisitMPEG(MPEG mpeg);
}

public class PlayVedioVisitor:VedioVisitor
{
 public override void VisitRM(RM rm)
 {
  rm.OpenFile();
  //实现RM的Play方法;
  rm.CloseFile();
 }

 public override void VisitMPEG(MPEG mpeg)
 {
  mpeg.OpenFile();
  //实现MPEG的Play方法;
  mpeg.CloseFile();
 }
}

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

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

请注意在Visit方法中传递节点对象的意图。目的就在于Visitor的行为中可能会调用被访问对象的固有行为,如Play行为中调用了OpenFile()和CloseFile()方法。但也可以不调用,如ShowScript和Resize行为。如果在你的设计中,不会出现调用被访问对象固有行为的情况,那么在Visit方法中删去该节点对象,也无不可。

根据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模式用到它最擅长的地方吧。让它不仅可行,而且还要可爱!

posted @ 2005-01-14 17:47  张逸  阅读(4256)  评论(3编辑  收藏