visitor模式
2013-05-22 22:27
295 查看
转自出处
"众口难调"出自宋·欧阳修《归田录》卷一："补仲山之衮，虽曲尽于巧心；和傅说之羹，实难调于众口。"其原意是各人的口味不同，很难做出一种饭菜使所有的人都感到好吃。众口是否真的难调呢？其实有个不错的办法可以解决众口难调的问题，那就是吃"自助餐"。
面对众口难调的问题去吃"自助餐"已经不是什么新鲜事，承办一个几百人、几千人的会议往往采用的都是自助餐的方式，让来宾各取所需，这就是所谓的以不变应万变。用更通俗的话来说，就是"东西都在这儿，自己看着办吧"。
在程序设计中解决这种众口难调的问题用的就是Visitor模式。在这里"众口难调"是指很难设计出一组对象（一桌饭菜）符合每个调用者的需要（口味），因为你根本就无法预料到这组对象的访问者是谁，有什么样的调用请求，访问什么样的数据。那么对付众口难调的方法"以不变应万变"在Visitor模式中就是指让一桌饭菜从你面前过，自己看着办就行了。
当然这里也有个先决条件，那就是你对每样饭菜都有一定的了解，自己才能做出选择。否则可能会瞪着一盘摆满小石子的盘子不知所措。反过来说，饭菜不需要知道来这里就餐的人的口味是什么，只管放出来让客人看着办就行了。这样，顾客和饭菜之间是不均衡的。顾客必须"有备而来"，但饭菜却对顾客却"一视同仁"。
using System;
using System.Collections;
abstract class Visitor
{
public abstract void VisitCoffee(Coffee c);
public abstract void VisitMeat(Meat m);
public abstract void VisitVegetable(Vegetable v);
}
class ZhangSan : Visitor
{
public override void VisitCoffee(Coffee c)
{
Console.Write( "{0}: Take a cup of {1}, ",this, c);
c.AddMilk();
c.AddSugar();
Console.WriteLine();
}
public override void VisitVegetable(Vegetable v)
{
Console.WriteLine( "{0}: Take some {1}", this, v );
}
public override void VisitMeat(Meat m)
{
Console.WriteLine( "I don't want any meat!");
}
}
class LiSi : Visitor
{
public override void VisitCoffee(Coffee c)
{
Console.Write( "{0}: Take a cup of {1}, ",this, c);
c.AddSugar();
Console.WriteLine();
}
public override void VisitVegetable(Vegetable v)
{
Console.WriteLine( "{0}: Take some {1}", this, v );
}
public override void VisitMeat(Meat m)
{
Console.WriteLine( "{0}: Take some {1}", this, m );
}
}
abstract class Food
{
abstract public void Accept( Visitor visitor );
}
class Coffee: Food
{
override public void Accept( Visitor visitor )
{
visitor.VisitCoffee( this );
}
public void AddSugar()
{
Console.Write("add sugar. ");
}
public void AddMilk()
{
Console.Write("add milk. ");
}
}
class Meat: Food
{
override public void Accept( Visitor visitor )
{
visitor.VisitMeat( this );
}
}
class Vegetable: Food
{
override public void Accept( Visitor visitor )
{
visitor.VisitVegetable( this );
}
}
class BuffetDinner
{
private ArrayList elements = new ArrayList();
public void Attach( Food element )
{
elements.Add( element );
}
public void Detach( Food element )
{
elements.Remove( element );
}
public void Accept( Visitor visitor )
{
foreach( Food f in elements )
f.Accept( visitor );
}
}
public class Client
{
public static void Main( string[] args )
{
BuffetDinner b = new BuffetDinner();
b.Attach(new Coffee());
b.Attach(new Vegetable());
b.Attach(new Meat());
ZhangSan z = new ZhangSan();
LiSi l = new LiSi();
b.Accept( z );
Console.WriteLine("----------------------");
b.Accept( l );
}
}
但是，Visitor模式中所蕴涵的思想绝非一个众口难调的例子所能完全表达的。其中还有"条件外置"（我起的名字）的含义在里面（应当归纳到"Find what vary and encapsulate it"的范畴，是我对这句话的理解），也就是说将条件判断从一个类中抽取出来，或交由专门的对象进行处理，或通过配置文件由用户手工控制。说白了就是做成"活"的。这种"条件外置"往往离不开多态的帮忙。面向对象中多态性是说，可以将子类型对象赋值给父类型对象，如果子类型复写了父类型的某个方法，那么当调用父类型对象的此方法时，自动转而调用子类型复写后的方法。条件外置在众多的模式中都有体现：
比如在简单工厂模式中，我们需要判断类型，然后进行加工，如下：
public Light Create(string LightType)
{
if(LightType == "Bulb")
return new BulbLight();
else if(LightType == "Tube")
return new TubeLight();
else
return null;
}
我们就可以让BulbLight与TubeLight共同继承自Light，再加上一个与之相对应的工厂架构，于是条件便外置到了客户端的手中：
public static void Main()
{
Creator c = new BulbCreator();
Light l = c.factory();
l.TurnOn();
l.TurnOff();
}
}
如果你想生产什么样子的灯泡就给 Creater c 赋值什么类型的工厂就行了。有人可能还会问，那什么时候使用什么类型的工厂不还是要进行条件判断吗，对了，条件外置后总还是要有人处理的，只不过不在Factory里面，也不在Light里面。你可以集中管理，也可以用配置文件，总之保证了系统绝大多数模块的稳定性。
另外，在策略模式的案例中，如果没有应用"策略模式"，那么我们也必须在业务对象中使用一个长长的If结构，判断何时使用哪个策略。但是借助多态性将"条件外置"后，便将判断控制权交由其他类进行处理，使得业务对象更加稳定。
至于到底将条件放到什么地方有很多解决办法，其一是放到一个专门的类中，这便应了《Design Pattern Explained》一书中的"Find what vary and Encapsulate it."这句话，发现变化的东西并且将其封装起来。其二，就是外置成基于XML或纯文本的配置文件，随时可以方便的进行修改。如果愿意，甚至可以编写一个图形化配置工具实现这一功能。
但是条件外置带来的"负"面影响便是需要"Design to Interface（针对接口或抽象编程）"。针对抽象编程增加了系统的稳定性，提高了可扩展性，并且让用户只与抽象打交道，恰好也应用了"最小知识原则"。但这对于必须了解对象类型的系统却是个灾难。Visitor模式便是在这个灾难中成活下来的一个很好的例子。虽然还有些争议，但解决的已经是很好了。
那么在Visitor模式中又是如何将"条件外置"的呢？这个外置工作恐怕比起前两种类型要复杂一些，用到了双重分派（Double Dispatch），所以我们还要从头说起。先让我们现看看没有用Visitor模式的"众口难调"的例子。
using System;
using System.Collections;
public class Visitor
{
public virtual void Visit(ArrayList dinner)
{
foreach(object f in dinner)
{
if(f is Coffee)
VisitCoffee((Coffee)f);
else if(f is Vegetable)
VisitVegetable((Vegetable)f);
else if(f is Meat)
VisitMeat((Meat)f);
else
{
// do nothing
}
}
}
protected virtual void VisitCoffee(Coffee c){}
protected virtual void VisitVegetable(Vegetable v){}
protected virtual void VisitMeat(Meat m){}
}
public class ZhangSan : Visitor
{
protected override void VisitCoffee(Coffee c)
{
Console.Write( "{0}: Take a cup of {1}, ",this, c);
c.AddMilk();
c.AddSugar();
Console.WriteLine();
}
protected override void VisitVegetable(Vegetable v)
{
Console.WriteLine( "{0}: Take some {1}", this, v );
}
protected override void VisitMeat(Meat m)
{
Console.WriteLine( "I don't want any meat!");
}
}
public class Coffee
{
public void AddSugar()
{
Console.Write("add sugar. ");
}
public void AddMilk()
{
Console.Write("add milk. ");
}
}
public class Meat
{
}
public class Vegetable
{
}
public class Client
{
private static ArrayList dinner = new ArrayList();
public static void Main( string[] args )
{
dinner.Add(new Coffee());
dinner.Add(new Vegetable());
dinner.Add(new Meat());
ZhangSan z = new ZhangSan();
z.Visit(dinner);
}
}
在这个例子中，各类食物没有公共父类，所以顾客在Visit的时候，必须将各类食物视作object，然后进行类型判断，再分别进行处理，处理时还不要忘了进行类型转换。长长的If结构会给系统引入很多不必要的麻烦，降低了系统的扩展性。
下面我对它应用条件外置：为了利用多态性，我们需要给条件中出现过的咖啡、蔬菜、肉赋予一个公共的父类"食物"。但这对我们这个例子这似乎是远远不够的。因为我们的顾客要"看菜吃饭"，如果利用多态性隐藏了类型信息，只针对抽象"食物"编程的化，我们便失去了"看菜吃饭"的功能，我想这是谁也不希望发生的事情。因此，我们唯一的方法就是多态后再进行"回调"，让每个具体类（咖啡、蔬菜、肉）自己报上名来，并且自己主动"回调"Visitor中与类型相关的方法。这样，Visitor只需撒下天罗地网，静待食物找上门来。这便是我对双重分派的一个认识。双重分派利用多态和回调消除了条件判断（这里没有外置条件），但也引入了一些新的问题：那就是当食物扩展时（比如说加入米饭），必须修改Visitor的天罗地网以提供米饭的回调函数，如果继承自Visitor的类很多的化，这个系统就变得脆弱起来。其实这也是我在后面要讨论的问题。
Visitor模式的的脆弱在于每个Visitor必须对所有它要访问的对象有个清晰的了解，一旦增加新类型对象，导致每个Visitor都必须发生变化。另外所有Element（在这个例子中是指具体食物）在进行回调的时候，也必须清楚回调的是Visitor的什么方法，方法名是什么等等，造成类与类之间耦合过于紧密。有没有更好的办法呢？我这里说说我的思路：
我的解决办法是二次利用多态性，并辅以模板方法模式（其实算不上模板方法，充其量算个缺省实现罢了）。C#中的多态性分成两个层面，一个是我们说的继承多态性，另外一个就是方法多态性。方法多态性是指某个类可以包含多个同名方法，但签名不同。系统在进行调用时自动匹配签名最相近的一个方法。我们平时使用最多的Console.WriteLine方法便有19个签名各异的"多态"。改造后的Visitor代码如下：
public class Visitor
{
public virtual void Visit(Meat m)
{ this.Visit((object)m); }
public virtual void Visit(Vegetable v)
{ this.Visit((object)v); }
public virtual void Visit(Coffee c)
{ this.Visit((object)c); }
public void Visit(Object f)
{
// do nothing
}
}
可见，Visit方法总共有四个不同的签名。在缺省实现中，各方法都转而调用public void Visit(Object f)方法，也就是什么都不作。当客户调用Visit方法时，会自动匹配类型。如果匹配不上的类型也会最终落到public void Visit(Object f)方法的怀抱中。在Visitor的子类中，只需实现关注的焦点就行了。例如某人只吃蔬菜不吃肉，那么他就没有必要再复写Visit(Meat m)方法了。这么做带来的另外一个好处就是，当添加新的食品时，即使不改变Visitor的代码，也不会产生任何编译或运行时的错误。如果修改，也只需修改Visitor类并提供一个缺省实现。Visitor的子类如果并不关心新增加的类，便可不做任何改动。完整的代码如下：
using System;
using System.Collections;
public class Visitor
{
public virtual void Visit(Meat m)
{ this.Visit((object)m); }
public virtual void Visit(Vegetable v)
{ this.Visit((object)v); }
public virtual void Visit(Coffee c)
{ this.Visit((object)c); }
public void Visit(Object o)
{
// do nothing
}
}
public class ZhangSan : Visitor
{
public override void Visit(Coffee c)
{
Console.Write( "{0}: Take a cup of {1}, ",this, c);
c.AddMilk();
c.AddSugar();
Console.WriteLine();
}
public override void Visit(Vegetable v)
{
Console.WriteLine( "{0}: Take some {1}", this, v );
}
}
public class LiSi : Visitor
{
public override void Visit(Coffee c)
{
Console.Write( "{0}: Take a cup of {1}, ",this, c);
c.AddSugar();
Console.WriteLine();
}
public override void Visit(Meat v)
{
Console.WriteLine( "{0}: Take some {1}", this, v );
}
}
public abstract class Food
{
public abstract void Accept( Visitor visitor );
}
public class Coffee: Food
{
public override void Accept( Visitor visitor )
{
visitor.Visit(this);
}
public void AddSugar()
{
Console.Write("add sugar. ");
}
public void AddMilk()
{
Console.Write("add milk. ");
}
}
public class Meat: Food
{
public override void Accept( Visitor visitor )
{
visitor.Visit(this);
}
}
public class Vegetable: Food
{
public override void Accept( Visitor visitor )
{
visitor.Visit(this);
}
}
public class BuffetDinner
{
private ArrayList elements = new ArrayList();
public void Attach( Food element )
{
elements.Add( element );
}
public void Detach( Food element )
{
elements.Remove( element );
}
public void Accept( Visitor visitor )
{
foreach( Food f in elements )
f.Accept( visitor );
}
}
public class Client
{
public static void Main( string[] args )
{
BuffetDinner b = new BuffetDinner();
b.Attach(new Coffee());
b.Attach(new Vegetable());
b.Attach(new Meat());
ZhangSan z = new ZhangSan();
LiSi l = new LiSi();
b.Accept( z );
Console.WriteLine("----------------------");
b.Accept( l );
}
}
"条件外置"是我对封装变化的一个理解。现在才发现，原来设计模式中还有很多深奥的东西等待开发呢。
"众口难调"出自宋·欧阳修《归田录》卷一："补仲山之衮，虽曲尽于巧心；和傅说之羹，实难调于众口。"其原意是各人的口味不同，很难做出一种饭菜使所有的人都感到好吃。众口是否真的难调呢？其实有个不错的办法可以解决众口难调的问题，那就是吃"自助餐"。
面对众口难调的问题去吃"自助餐"已经不是什么新鲜事，承办一个几百人、几千人的会议往往采用的都是自助餐的方式，让来宾各取所需，这就是所谓的以不变应万变。用更通俗的话来说，就是"东西都在这儿，自己看着办吧"。
在程序设计中解决这种众口难调的问题用的就是Visitor模式。在这里"众口难调"是指很难设计出一组对象（一桌饭菜）符合每个调用者的需要（口味），因为你根本就无法预料到这组对象的访问者是谁，有什么样的调用请求，访问什么样的数据。那么对付众口难调的方法"以不变应万变"在Visitor模式中就是指让一桌饭菜从你面前过，自己看着办就行了。
当然这里也有个先决条件，那就是你对每样饭菜都有一定的了解，自己才能做出选择。否则可能会瞪着一盘摆满小石子的盘子不知所措。反过来说，饭菜不需要知道来这里就餐的人的口味是什么，只管放出来让客人看着办就行了。这样，顾客和饭菜之间是不均衡的。顾客必须"有备而来"，但饭菜却对顾客却"一视同仁"。
using System;
using System.Collections;
abstract class Visitor
{
public abstract void VisitCoffee(Coffee c);
public abstract void VisitMeat(Meat m);
public abstract void VisitVegetable(Vegetable v);
}
class ZhangSan : Visitor
{
public override void VisitCoffee(Coffee c)
{
Console.Write( "{0}: Take a cup of {1}, ",this, c);
c.AddMilk();
c.AddSugar();
Console.WriteLine();
}
public override void VisitVegetable(Vegetable v)
{
Console.WriteLine( "{0}: Take some {1}", this, v );
}
public override void VisitMeat(Meat m)
{
Console.WriteLine( "I don't want any meat!");
}
}
class LiSi : Visitor
{
public override void VisitCoffee(Coffee c)
{
Console.Write( "{0}: Take a cup of {1}, ",this, c);
c.AddSugar();
Console.WriteLine();
}
public override void VisitVegetable(Vegetable v)
{
Console.WriteLine( "{0}: Take some {1}", this, v );
}
public override void VisitMeat(Meat m)
{
Console.WriteLine( "{0}: Take some {1}", this, m );
}
}
abstract class Food
{
abstract public void Accept( Visitor visitor );
}
class Coffee: Food
{
override public void Accept( Visitor visitor )
{
visitor.VisitCoffee( this );
}
public void AddSugar()
{
Console.Write("add sugar. ");
}
public void AddMilk()
{
Console.Write("add milk. ");
}
}
class Meat: Food
{
override public void Accept( Visitor visitor )
{
visitor.VisitMeat( this );
}
}
class Vegetable: Food
{
override public void Accept( Visitor visitor )
{
visitor.VisitVegetable( this );
}
}
class BuffetDinner
{
private ArrayList elements = new ArrayList();
public void Attach( Food element )
{
elements.Add( element );
}
public void Detach( Food element )
{
elements.Remove( element );
}
public void Accept( Visitor visitor )
{
foreach( Food f in elements )
f.Accept( visitor );
}
}
public class Client
{
public static void Main( string[] args )
{
BuffetDinner b = new BuffetDinner();
b.Attach(new Coffee());
b.Attach(new Vegetable());
b.Attach(new Meat());
ZhangSan z = new ZhangSan();
LiSi l = new LiSi();
b.Accept( z );
Console.WriteLine("----------------------");
b.Accept( l );
}
}
但是，Visitor模式中所蕴涵的思想绝非一个众口难调的例子所能完全表达的。其中还有"条件外置"（我起的名字）的含义在里面（应当归纳到"Find what vary and encapsulate it"的范畴，是我对这句话的理解），也就是说将条件判断从一个类中抽取出来，或交由专门的对象进行处理，或通过配置文件由用户手工控制。说白了就是做成"活"的。这种"条件外置"往往离不开多态的帮忙。面向对象中多态性是说，可以将子类型对象赋值给父类型对象，如果子类型复写了父类型的某个方法，那么当调用父类型对象的此方法时，自动转而调用子类型复写后的方法。条件外置在众多的模式中都有体现：
比如在简单工厂模式中，我们需要判断类型，然后进行加工，如下：
public Light Create(string LightType)
{
if(LightType == "Bulb")
return new BulbLight();
else if(LightType == "Tube")
return new TubeLight();
else
return null;
}
我们就可以让BulbLight与TubeLight共同继承自Light，再加上一个与之相对应的工厂架构，于是条件便外置到了客户端的手中：
public static void Main()
{
Creator c = new BulbCreator();
Light l = c.factory();
l.TurnOn();
l.TurnOff();
}
}
如果你想生产什么样子的灯泡就给 Creater c 赋值什么类型的工厂就行了。有人可能还会问，那什么时候使用什么类型的工厂不还是要进行条件判断吗，对了，条件外置后总还是要有人处理的，只不过不在Factory里面，也不在Light里面。你可以集中管理，也可以用配置文件，总之保证了系统绝大多数模块的稳定性。
另外，在策略模式的案例中，如果没有应用"策略模式"，那么我们也必须在业务对象中使用一个长长的If结构，判断何时使用哪个策略。但是借助多态性将"条件外置"后，便将判断控制权交由其他类进行处理，使得业务对象更加稳定。
至于到底将条件放到什么地方有很多解决办法，其一是放到一个专门的类中，这便应了《Design Pattern Explained》一书中的"Find what vary and Encapsulate it."这句话，发现变化的东西并且将其封装起来。其二，就是外置成基于XML或纯文本的配置文件，随时可以方便的进行修改。如果愿意，甚至可以编写一个图形化配置工具实现这一功能。
但是条件外置带来的"负"面影响便是需要"Design to Interface（针对接口或抽象编程）"。针对抽象编程增加了系统的稳定性，提高了可扩展性，并且让用户只与抽象打交道，恰好也应用了"最小知识原则"。但这对于必须了解对象类型的系统却是个灾难。Visitor模式便是在这个灾难中成活下来的一个很好的例子。虽然还有些争议，但解决的已经是很好了。
那么在Visitor模式中又是如何将"条件外置"的呢？这个外置工作恐怕比起前两种类型要复杂一些，用到了双重分派（Double Dispatch），所以我们还要从头说起。先让我们现看看没有用Visitor模式的"众口难调"的例子。
using System;
using System.Collections;
public class Visitor
{
public virtual void Visit(ArrayList dinner)
{
foreach(object f in dinner)
{
if(f is Coffee)
VisitCoffee((Coffee)f);
else if(f is Vegetable)
VisitVegetable((Vegetable)f);
else if(f is Meat)
VisitMeat((Meat)f);
else
{
// do nothing
}
}
}
protected virtual void VisitCoffee(Coffee c){}
protected virtual void VisitVegetable(Vegetable v){}
protected virtual void VisitMeat(Meat m){}
}
public class ZhangSan : Visitor
{
protected override void VisitCoffee(Coffee c)
{
Console.Write( "{0}: Take a cup of {1}, ",this, c);
c.AddMilk();
c.AddSugar();
Console.WriteLine();
}
protected override void VisitVegetable(Vegetable v)
{
Console.WriteLine( "{0}: Take some {1}", this, v );
}
protected override void VisitMeat(Meat m)
{
Console.WriteLine( "I don't want any meat!");
}
}
public class Coffee
{
public void AddSugar()
{
Console.Write("add sugar. ");
}
public void AddMilk()
{
Console.Write("add milk. ");
}
}
public class Meat
{
}
public class Vegetable
{
}
public class Client
{
private static ArrayList dinner = new ArrayList();
public static void Main( string[] args )
{
dinner.Add(new Coffee());
dinner.Add(new Vegetable());
dinner.Add(new Meat());
ZhangSan z = new ZhangSan();
z.Visit(dinner);
}
}
在这个例子中，各类食物没有公共父类，所以顾客在Visit的时候，必须将各类食物视作object，然后进行类型判断，再分别进行处理，处理时还不要忘了进行类型转换。长长的If结构会给系统引入很多不必要的麻烦，降低了系统的扩展性。
下面我对它应用条件外置：为了利用多态性，我们需要给条件中出现过的咖啡、蔬菜、肉赋予一个公共的父类"食物"。但这对我们这个例子这似乎是远远不够的。因为我们的顾客要"看菜吃饭"，如果利用多态性隐藏了类型信息，只针对抽象"食物"编程的化，我们便失去了"看菜吃饭"的功能，我想这是谁也不希望发生的事情。因此，我们唯一的方法就是多态后再进行"回调"，让每个具体类（咖啡、蔬菜、肉）自己报上名来，并且自己主动"回调"Visitor中与类型相关的方法。这样，Visitor只需撒下天罗地网，静待食物找上门来。这便是我对双重分派的一个认识。双重分派利用多态和回调消除了条件判断（这里没有外置条件），但也引入了一些新的问题：那就是当食物扩展时（比如说加入米饭），必须修改Visitor的天罗地网以提供米饭的回调函数，如果继承自Visitor的类很多的化，这个系统就变得脆弱起来。其实这也是我在后面要讨论的问题。
Visitor模式的的脆弱在于每个Visitor必须对所有它要访问的对象有个清晰的了解，一旦增加新类型对象，导致每个Visitor都必须发生变化。另外所有Element（在这个例子中是指具体食物）在进行回调的时候，也必须清楚回调的是Visitor的什么方法，方法名是什么等等，造成类与类之间耦合过于紧密。有没有更好的办法呢？我这里说说我的思路：
我的解决办法是二次利用多态性，并辅以模板方法模式（其实算不上模板方法，充其量算个缺省实现罢了）。C#中的多态性分成两个层面，一个是我们说的继承多态性，另外一个就是方法多态性。方法多态性是指某个类可以包含多个同名方法，但签名不同。系统在进行调用时自动匹配签名最相近的一个方法。我们平时使用最多的Console.WriteLine方法便有19个签名各异的"多态"。改造后的Visitor代码如下：
public class Visitor
{
public virtual void Visit(Meat m)
{ this.Visit((object)m); }
public virtual void Visit(Vegetable v)
{ this.Visit((object)v); }
public virtual void Visit(Coffee c)
{ this.Visit((object)c); }
public void Visit(Object f)
{
// do nothing
}
}
可见，Visit方法总共有四个不同的签名。在缺省实现中，各方法都转而调用public void Visit(Object f)方法，也就是什么都不作。当客户调用Visit方法时，会自动匹配类型。如果匹配不上的类型也会最终落到public void Visit(Object f)方法的怀抱中。在Visitor的子类中，只需实现关注的焦点就行了。例如某人只吃蔬菜不吃肉，那么他就没有必要再复写Visit(Meat m)方法了。这么做带来的另外一个好处就是，当添加新的食品时，即使不改变Visitor的代码，也不会产生任何编译或运行时的错误。如果修改，也只需修改Visitor类并提供一个缺省实现。Visitor的子类如果并不关心新增加的类，便可不做任何改动。完整的代码如下：
using System;
using System.Collections;
public class Visitor
{
public virtual void Visit(Meat m)
{ this.Visit((object)m); }
public virtual void Visit(Vegetable v)
{ this.Visit((object)v); }
public virtual void Visit(Coffee c)
{ this.Visit((object)c); }
public void Visit(Object o)
{
// do nothing
}
}
public class ZhangSan : Visitor
{
public override void Visit(Coffee c)
{
Console.Write( "{0}: Take a cup of {1}, ",this, c);
c.AddMilk();
c.AddSugar();
Console.WriteLine();
}
public override void Visit(Vegetable v)
{
Console.WriteLine( "{0}: Take some {1}", this, v );
}
}
public class LiSi : Visitor
{
public override void Visit(Coffee c)
{
Console.Write( "{0}: Take a cup of {1}, ",this, c);
c.AddSugar();
Console.WriteLine();
}
public override void Visit(Meat v)
{
Console.WriteLine( "{0}: Take some {1}", this, v );
}
}
public abstract class Food
{
public abstract void Accept( Visitor visitor );
}
public class Coffee: Food
{
public override void Accept( Visitor visitor )
{
visitor.Visit(this);
}
public void AddSugar()
{
Console.Write("add sugar. ");
}
public void AddMilk()
{
Console.Write("add milk. ");
}
}
public class Meat: Food
{
public override void Accept( Visitor visitor )
{
visitor.Visit(this);
}
}
public class Vegetable: Food
{
public override void Accept( Visitor visitor )
{
visitor.Visit(this);
}
}
public class BuffetDinner
{
private ArrayList elements = new ArrayList();
public void Attach( Food element )
{
elements.Add( element );
}
public void Detach( Food element )
{
elements.Remove( element );
}
public void Accept( Visitor visitor )
{
foreach( Food f in elements )
f.Accept( visitor );
}
}
public class Client
{
public static void Main( string[] args )
{
BuffetDinner b = new BuffetDinner();
b.Attach(new Coffee());
b.Attach(new Vegetable());
b.Attach(new Meat());
ZhangSan z = new ZhangSan();
LiSi l = new LiSi();
b.Accept( z );
Console.WriteLine("----------------------");
b.Accept( l );
}
}
"条件外置"是我对封装变化的一个理解。现在才发现，原来设计模式中还有很多深奥的东西等待开发呢。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 【ASM系列1】visitor模式
- 访问者（Visitor）模式--------访问数据结构并处理数据
- 23设计模式之访问者模式(Visitor)
- 设计模式--访问者模式Visitor（行为型）
- 设计模式之Visitor(访问者)
- C++设计模式之二十三：Visitor（访问者模式）
- 设计模式 ( 二十 ) 访问者模式Visitor（对象行为型）
- Visitor模式示例（使用Loki类库）
- 用C#实现Visitor模式
- 23种设计模式之python实现--visitor模式
- 设计模式22——Visitor设计模式
- Visitor(访问者)设计模式
- 关于Visitor模式突然想到的
- 设计模式(二十三)----- 访问者模式(visitor)----(JAVA版)
- 行为模式之十一---Visitor
- 设计模式之二十四：访问者模式(Visitor)
- 深入浅出设计模式(22)——Visitor模式
- Design Pattern Visitor 访问者设计模式
- Visitor - 访问者模式
- Java设计模式之Visitor