Chemmy's Blog

Visitor，访问者模式：表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素类的前提下定义作用于这个元素的新操作。
http://www.cnblogs.com/zhili/p/VistorPattern.html
http://www.cnblogs.com/PatrickLiu/p/8135083.html

　　在上一篇博文中分享了责任链模式，责任链模式主要应用在系统中的某些功能需要多个对象参与才能完成的场景。在这篇博文中，我将为大家分享我对访问者模式的理解。

2.1 访问者模式的定义

 　　访问者模式是封装一些施加于某种数据结构之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构则可以保存不变。访问者模式适用于数据结构相对稳定的系统， 它把数据结构和作用于数据结构之上的操作之间的耦合度降低，使得操作集合可以相对自由地改变。

　　数据结构的每一个节点都可以接受一个访问者的调用，此节点向访问者对象传入节点对象，而访问者对象则反过来执行节点对象的操作。这样的过程叫做“双重分派”。节点调用访问者，将它自己传入，访问者则将某算法针对此节点执行。

2.2 访问者模式的结构图

 　　从上面描述可知，访问者模式是用来封装某种数据结构中的方法。具体封装过程是：每个元素接受一个访问者的调用，每个元素的Accept方法接受访问者对象作为参数传入，访问者对象则反过来调用元素对象的操作。具体的访问者模式结构图如下所示。

　　这里需要明确一点：访问者模式中具体访问者的数目和具体节点的数目没有任何关系。从访问者的结构图可以看出，访问者模式涉及以下几类角色。

• 抽象访问者角色（Vistor）:声明一个活多个访问操作，使得所有具体访问者必须实现的接口。
• 具体访问者角色（ConcreteVistor）：实现抽象访问者角色中所有声明的接口。
• 抽象节点角色（Element）：声明一个接受操作，接受一个访问者对象作为参数。
• 具体节点角色（ConcreteElement）：实现抽象元素所规定的接受操作。
• 结构对象角色（ObjectStructure）：节点的容器，可以包含多个不同类或接口的容器。

2.3 访问者模式的实现

 　　在讲诉访问者模式的实现时，我想先不用访问者模式的方式来实现某个场景。具体场景是——现在我想遍历每个元素对象，然后调用每个元素对象的Print方法来打印该元素对象的信息。如果此时不采用访问者模式的话，实现这个场景再简单不过了，具体实现代码如下所示：

1 namespace DonotUsevistorPattern 2 {
3 // 抽象元素角色
4 public abstract class Element 5 {
6 public abstract void Print(); 7 }
8
9 // 具体元素A
10 public class ElementA : Element 11 { 12 public override void Print() 13 { 14 Console.WriteLine(“我是元素A”); 15 } 16 } 17
18 // 具体元素B
19 public class ElementB : Element 20 { 21 public override void Print() 22 { 23 Console.WriteLine(“我是元素B”); 24 } 25 } 26
27 // 对象结构
28 public class ObjectStructure 29 { 30 private ArrayList elements = new ArrayList(); 31
32 public ArrayList Elements 33 { 34 get { return elements; } 35 } 36
37 public ObjectStructure() 38 { 39 Random ran = new Random(); 40 for (int i = 0; i < 6; i++) 41 { 42 int ranNum = ran.Next(10); 43 if (ranNum > 5) 44 { 45 elements.Add(new ElementA()); 46 } 47 else
48 { 49 elements.Add(new ElementB()); 50 } 51 } 52 } 53 } 54
55 class Program 56 { 57 static void Main(string[] args) 58 { 59 ObjectStructure objectStructure = new ObjectStructure(); 60 // 遍历对象结构中的对象集合，访问每个元素的Print方法打印元素信息
61 foreach (Element e in objectStructure.Elements) 62 { 63 e.Print(); 64 } 65
66 Console.Read(); 67 } 68 } 69 }

　　上面代码很准确了解决了我们刚才提出的场景，但是需求在时刻变化的，如果此时，我除了想打印元素的信息外，还想打印出元素被访问的时间，此时我们就不得不去修改每个元素的Print方法，再加入相对应的输入访问时间的输出信息。这样的设计显然不符合“开-闭”原则，即某个方法操作的改变，会使得必须去更改每个元素类。既然，这里变化的点是操作的改变，而每个元素的数据结构是不变的。所以此时就思考——能不能把操作于元素的操作和元素本身的数据结构分开呢？解开这两者的耦合度，这样如果是操作发现变化时，就不需要去更改元素本身了，但是如果是元素数据结构发现变化，例如，添加了某个字段，这样就不得不去修改元素类了。此时，我们可以使用访问者模式来解决这个问题，即把作用于具体元素的操作由访问者对象来调用。具体的实现代码如下所示：

1 namespace VistorPattern 2 {
3 // 抽象元素角色
4 public abstract class Element 5 {
6 public abstract void Accept(IVistor vistor); 7 public abstract void Print(); 8 }
9
10 // 具体元素A
11 public class ElementA :Element 12 {
13 public override void Accept(IVistor vistor) 14 {
15 // 调用访问者visit方法
16 vistor.Visit(this);
17 }
18 public override void Print() 19 {
20 Console.WriteLine(“我是元素A”);
21 }
22 }
23
24 // 具体元素B
25 public class ElementB :Element 26 {
27 public override void Accept(IVistor vistor) 28 {
29 vistor.Visit(this);
30 }
31 public override void Print() 32 {
33 Console.WriteLine(“我是元素B”);
34 }
35 }
36
37 // 抽象访问者
38 public interface IVistor 39 {
40 void Visit(ElementA a); 41 void Visit(ElementB b); 42 }
43
44 // 具体访问者
45 public class ConcreteVistor :IVistor 46 {
47 // visit方法而是再去调用元素的Accept方法
48 public void Visit(ElementA a) 49 {
50 a.Print();
51 }
52 public void Visit(ElementB b) 53 {
54 b.Print();
55 }
56 }
57
58 // 对象结构
59 public class ObjectStructure 60 {
61 private ArrayList elements = new ArrayList(); 62
63 public ArrayList Elements 64 {
65 get { return elements; } 66 }
67
68 public ObjectStructure() 69 {
70 Random ran = new Random(); 71 for (int i = 0; i < 6; i++)
72 {
73 int ranNum = ran.Next(10);
74 if (ranNum > 5)
75 {
76 elements.Add(new ElementA()); 77 }
78 else
79 {
80 elements.Add(new ElementB()); 81 }
82 }
83 }
84 }
85
86 class Program 87 {
88 static void Main(string[] args)
89 {
90 ObjectStructure objectStructure = new ObjectStructure(); 91 foreach (Element e in objectStructure.Elements) 92 {
93 // 每个元素接受访问者访问
94 e.Accept(new ConcreteVistor()); 95 }
96
97 Console.Read();
98 }
99 } 100 }

　　从上面代码可知，使用访问者模式实现上面场景后，元素Print方法的访问封装到了访问者对象中了（我觉得可以把Print方法封装到具体访问者对象中。），此时客户端与元素的Print方法就隔离开了。此时，如果需要添加打印访问时间的需求时，此时只需要再添加一个具体的访问者类即可。此时就不需要去修改元素中的Print()方法了。

 　　每个设计模式都有其应当使用的情况，那让我们看看访问者模式具体应用场景。如果遇到以下场景，此时我们可以考虑使用访问者模式。

• 如果系统有比较稳定的数据结构，而又有易于变化的算法时，此时可以考虑使用访问者模式。因为访问者模式使得算法操作的添加比较容易。
• 如果一组类中，存在着相似的操作，为了避免出现大量重复的代码，可以考虑把重复的操作封装到访问者中。（当然也可以考虑使用抽象类了）
• 如果一个对象存在着一些与本身对象不相干，或关系比较弱的操作时，为了避免操作污染这个对象，则可以考虑把这些操作封装到访问者对象中。

 　　访问者模式具有以下优点：

• 访问者模式使得添加新的操作变得容易。如果一些操作依赖于一个复杂的结构对象的话，那么一般而言，添加新的操作会变得很复杂。而使用访问者模式，增加新的操作就意味着添加一个新的访问者类。因此，使得添加新的操作变得容易。
• 访问者模式使得有关的行为操作集中到一个访问者对象中，而不是分散到一个个的元素类中。这点类似与”中介者模式”。
• 访问者模式可以访问属于不同的等级结构的成员对象，而迭代只能访问属于同一个等级结构的成员对象。

　　访问者模式也有如下的缺点：

• 增加新的元素类变得困难。每增加一个新的元素意味着要在抽象访问者角色中增加一个新的抽象操作，并在每一个具体访问者类中添加相应的具体操作。

　　访问者模式是用来封装一些施加于某种数据结构之上的操作。它使得可以在不改变元素本身的前提下增加作用于这些元素的新操作，访问者模式的目的是把操作从数据结构中分离出来。

　　在现实生活中，有很多请求并不是一个人说了就算的，例如面试时的工资，低于1万的薪水可能技术经理就可以决定了，但是1万~1万5的薪水可能技术经理就没这个权利批准，可能就需要请求技术总监的批准，所以在面试的完后，经常会有面试官说，你这个薪水我这边觉得你这技术可以拿这个薪水的，但是还需要技术总监的批准等的话。这个例子也就诠释了本文要介绍的内容。生活中的这个例子真是应用了责任链模式。

二、责任链模式介绍

2.1 责任链模式的定义

　　从生活中的例子可以发现，某个请求可能需要几个人的审批，即使技术经理审批完了，还需要上一级的审批。这样的例子，还有公司中的请假，少于3天的，直属Leader就可以批准，3天到7天之内就需要项目经理批准，多余7天的就需要技术总监的批准了。介绍了这么多生活中责任链模式的例子的，下面具体给出面向对象中责任链模式的定义。

　　责任链模式指的是——某个请求需要多个对象进行处理，从而避免请求的发送者和接收之间的耦合关系。将这些对象连成一条链子，并沿着这条链子传递该请求，直到有对象处理它为止。

2.2 责任链模式的结构图

　　从责任链模式的定义可以发现，责任链模式涉及的对象只有处理者角色，但由于有多个处理者，它们具有共同的处理请求的方法，所以这里抽象出一个抽象处理者角色进行代码复用。这样分析下来，责任链模式的结构图也就不言而喻了，具体结构图如下所示。

　　主要涉及两个角色：

• 抽象处理者角色（Handler）：定义出一个处理请求的接口。这个接口通常由接口或抽象类来实现。
• 具体处理者角色（ConcreteHandler）：具体处理者接受到请求后，可以选择将该请求处理掉，或者将请求传给下一个处理者。因此，每个具体处理者需要保存下一个处理者的引用，以便把请求传递下去。

2.3 责任链模式的实现

　　有了上面的介绍，下面以公司采购东西为例子来实现责任链模式。公司规定，采购架构总价在1万之内，经理级别的人批准即可，总价大于1万小于2万5的则还需要副总进行批准，总价大于2万5小于10万的需要还需要总经理批准，而大于总价大于10万的则需要组织一个会议进行讨论。对于这样一个需求，最直观的方法就是设计一个方法，参数是采购的总价，然后在这个方法内对价格进行调整判断，然后针对不同的条件交给不同级别的人去处理，这样确实可以解决问题，但这样一来，我们就需要多重if-else语句来进行判断，但当加入一个新的条件范围时，我们又不得不去修改原来设计的方法来再添加一个条件判断，这样的设计显然违背了“开-闭”原则。这时候，可以采用责任链模式来解决这样的问题。具体实现代码如下所示。

namespace ChainofResponsibility
{ // 采购请求
public class PurchaseRequest
{ // 金额
public double Amount { get; set; } // 产品名字
public string ProductName { get; set; } public PurchaseRequest(double amount, string productName)
{
Amount = amount;
ProductName = productName;
}
} // 审批人,Handler
public abstract class Approver
{ public Approver NextApprover { get; set; } public string Name { get; set; } public Approver(string name)
{ this.Name = name;
} public abstract void ProcessRequest(PurchaseRequest request);
} // ConcreteHandler
public class Manager : Approver
{ public Manager(string name)
: base(name)
{ } public override void ProcessRequest(PurchaseRequest request)
{ if (request.Amount < 10000.0)
{
Console.WriteLine(“{0}-{1} approved the request of purshing {2}”, this, Name, request.ProductName);
} else if (NextApprover != null)
{
NextApprover.ProcessRequest(request);
}
}
} // ConcreteHandler,副总
public class VicePresident : Approver
{ public VicePresident(string name)
: base(name)
{
} public override void ProcessRequest(PurchaseRequest request)
{ if (request.Amount < 25000.0)
{
Console.WriteLine(“{0}-{1} approved the request of purshing {2}”, this, Name, request.ProductName);
} else if (NextApprover != null)
{
NextApprover.ProcessRequest(request);
}
}
} // ConcreteHandler，总经理
public class President :Approver
{ public President(string name)
: base(name)
{ } public override void ProcessRequest(PurchaseRequest request)
{ if (request.Amount < 100000.0)
{
Console.WriteLine(“{0}-{1} approved the request of purshing {2}”, this, Name, request.ProductName);
} else {
Console.WriteLine(“Request需要组织一个会议讨论”);
}
}
} class Program
{ static void Main(string[] args)
{
PurchaseRequest requestTelphone = new PurchaseRequest(4000.0, “Telphone”);
PurchaseRequest requestSoftware = new PurchaseRequest(10000.0, “Visual Studio”);
PurchaseRequest requestComputers = new PurchaseRequest(40000.0, “Computers”);

        Approver manager \= new Manager("LearningHard");
        Approver Vp \= new VicePresident("Tony");
        Approver Pre \= new President("BossTom"); // 设置责任链
        manager.NextApprover = Vp;
        Vp.NextApprover \= Pre; // 处理请求

manager.ProcessRequest(requestTelphone);
manager.ProcessRequest(requestSoftware);
manager.ProcessRequest(requestComputers);
Console.ReadLine();
}
}
}

　　既然，原来的设计会因为价格条件范围的变化而导致不利于扩展，根据“封装变化”的原则，此时我们想的自然是能不能把价格范围细化到不同的类中呢？因为每个价格范围都决定某个批准者，这里就联想到创建多个批准类，这样每个类中只需要针对他自己这个范围的价格判断。这样也就是责任链的最后实现方式了，具体的运行结果如下图所示。

　　在以下场景中可以考虑使用责任链模式：

• 一个系统的审批需要多个对象才能完成处理的情况下，例如请假系统等。
• 代码中存在多个if-else语句的情况下，此时可以考虑使用责任链模式来对代码进行重构。

　　责任链模式的优点不言而喻，主要有以下点：

• 降低了请求的发送者和接收者之间的耦合。
• 把多个条件判定分散到各个处理类中，使得代码更加清晰，责任更加明确。

　　责任链模式也具有一定的缺点，如：

• 在找到正确的处理对象之前，所有的条件判定都要执行一遍，当责任链过长时，可能会引起性能的问题
• 可能导致某个请求不被处理。

　　责任链降低了请求端和接收端之间的耦合，使多个对象都有机会处理某个请求。如考试中作弊传纸条，泡妞传情书一般。在下一章将继续分享访问者模式。

Iterator，迭代器模式：提供一个方法顺序访问一个聚合对象的各个元素，而又不需要暴露该对象的内部表示。 应用场景：迭代。

http://www.cnblogs.com/zhili/p/IteratorPattern.html
http://www.cnblogs.com/PatrickLiu/p/7903617.html

Adapter,适配器模式：将一类的接口转换成客户希望的另外一个接口，Adapter模式使得原本由于接口不兼容而不能一起工作那些类可以一起工作。

http://www.cnblogs.com/PatrickLiu/p/7660554.html
http://www.cnblogs.com/zhili/p/AdapterPattern.html

一、引言

在实际的开发过程中，由于应用环境的变化（例如使用语言的变化），我们需要的实现在新的环境中没有现存对象可以满足，但是其他环境却存在这样现存的对象。那么如果将“将现存的对象”在新的环境中进行调用呢？解决这个问题的办法就是我们本文要介绍的适配器模式——使得新环境中不需要去重复实现已经存在了的实现而很好地把现有对象（指原来环境中的现有对象）加入到新环境来使用。

二、适配器模式的详细介绍

2.1 定义

下面让我们看看适配器的定义，适配器模式——把一个类的接口变换成客户端所期待的另一种接口，从而使原本接口不匹配而无法一起工作的两个类能够在一起工作。适配器模式有类的适配器模式和对象的适配器模式两种形式，下面我们分别讨论这两种形式的实现和给出对应的类图来帮助大家理清类之间的关系。

2.2  类的适配器模式实现

在这里以生活中的一个例子来进行演示适配器模式的实现，具体场景是: 在生活中，我们买的电器插头是2个孔的，但是我们买的插座只有三个孔的，此时我们就希望电器的插头可以转换为三个孔的就好，这样我们就可以直接把它插在插座上，此时三个孔插头就是客户端期待的另一种接口，自然两个孔的插头就是现有的接口，适配器模式就是用来完成这种转换的，具体实现代码如下：

using System; /// 这里以插座和插头的例子来诠释适配器模式 /// 现在我们买的电器插头是2个孔，但是我们买的插座只有3个孔的 /// 这是我们想把电器插在插座上的话就需要一个电适配器
namespace 设计模式之适配器模式
{ ///

/// 客户端，客户想要把2个孔的插头 转变成三个孔的插头，这个转变交给适配器就好 /// 既然适配器需要完成这个功能，所以它必须同时具体2个孔插头和三个孔插头的特征 ///

class Client
{ static void Main(string[] args)
{ // 现在客户端可以通过电适配要使用2个孔的插头了
IThreeHole threehole = new PowerAdapter();
threehole.Request();
Console.ReadLine();
}
} ///

/// 三个孔的插头，也就是适配器模式中的目标角色 ///

public interface IThreeHole
{ void Request();
} ///

/// 两个孔的插头，源角色——需要适配的类 ///

public abstract class TwoHole
{ public void SpecificRequest()
{
Console.WriteLine(“我是两个孔的插头”);
}
} ///

/// 适配器类，接口要放在类的后面 /// 适配器类提供了三个孔插头的行为，但其本质是调用两个孔插头的方法 ///

public class PowerAdapter:TwoHole,IThreeHole
{ ///

/// 实现三个孔插头接口方法 ///

public void Request()
{ // 调用两个孔插头方法
this.SpecificRequest();
}
}
}

从上面代码中可以看出，客户端希望调用Request方法（即三个孔插头），但是我们现有的类（即2个孔的插头）并没有Request方法，它只有SpecificRequest方法（即两个孔插头本身的方法），然而适配器类（适配器必须实现三个孔插头接口和继承两个孔插头类）可以提供这种转换，它提供了Request方法的实现（其内部调用的是两个孔插头，因为适配器只是一个外壳罢了，包装着两个孔插头（因为只有这样，电器才能使用），并向外界提供三个孔插头的外观，）以供客户端使用。

2.3 类图

上面实现中，因为适配器（PowerAdapter类）与源角色（TwoHole类）是继承关系，所以该适配器模式是类的适配器模式，具体对应的类图为：

2.4 对象的适配器模式

上面都是类的适配器模式的介绍，然而适配器模式还有另外一种形式——对象的适配器模式，这里就具体讲解下它的实现，实现的分析思路：既然现在适配器类不能继承TwoHole抽象类了（因为用继承就属于类的适配器了），但是适配器类无论如何都要实现客户端期待的方法的，即Request方法，所以一定是要继承ThreeHole抽象类或IThreeHole接口的，然而适配器类的Request方法又必须调用TwoHole的SpecificRequest方法，又不能用继承，这时候就想，不能继承，但是我们可以在适配器类中创建TwoHole对象，然后在Requst中使用TwoHole的方法了。正如我们分析的那样，对象的适配器模式的实现正式如此。下面就让我看看具体实现代码：

namespace 对象的适配器模式
{ class Client
{ static void Main(string[] args)
{ // 现在客户端可以通过电适配要使用2个孔的插头了
ThreeHole threehole = new PowerAdapter();
threehole.Request();
Console.ReadLine();
}
} ///

/// 三个孔的插头，也就是适配器模式中的目标(Target)角色 ///

public class ThreeHole
{ // 客户端需要的方法
public virtual void Request()
{ // 可以把一般实现放在这里
}
} ///

/// 两个孔的插头，源角色——需要适配的类 ///

public class TwoHole
{ public void SpecificRequest()
{
Console.WriteLine(“我是两个孔的插头”);
}
} ///

/// 适配器类，这里适配器类没有TwoHole类， /// 而是引用了TwoHole对象，所以是对象的适配器模式的实现 ///

public class PowerAdapter : ThreeHole
{ // 引用两个孔插头的实例,从而将客户端与TwoHole联系起来
public TwoHole twoholeAdaptee = new TwoHole(); ///

/// 实现三个孔插头接口方法 ///

public override void Request()
{
twoholeAdaptee.SpecificRequest();
}
}
}

从上面代码可以看出,对象的适配器模式正如我们开始分析的思路去实现的, 其中客户端调用代码和类的适配器实现基本相同,下面让我们看看对象的适配器模式的类图,具体类图如下:

三、适配器模式的优缺点

在引言部分已经提出,适配器模式用来解决现有对象与客户端期待接口不一致的问题,下面详细总结下适配器两种形式的优缺点。

类的适配器模式：

优点：

• 可以在不修改原有代码的基础上来复用现有类，很好地符合 “开闭原则”
• 可以重新定义Adaptee(被适配的类)的部分行为，因为在类适配器模式中，Adapter是Adaptee的子类
• 仅仅引入一个对象，并不需要额外的字段来引用Adaptee实例（这个即是优点也是缺点）。

缺点：

• 用一个具体的Adapter类对Adaptee和Target进行匹配，当如果想要匹配一个类以及所有它的子类时，类的适配器模式就不能胜任了。因为类的适配器模式中没有引入Adaptee的实例，光调用this.SpecificRequest方法并不能去调用它对应子类的SpecificRequest方法。
• 采用了 “多继承”的实现方式，带来了不良的高耦合。

对象的适配器模式

优点：

• 可以在不修改原有代码的基础上来复用现有类，很好地符合 “开闭原则”（这点是两种实现方式都具有的）
• 采用 “对象组合”的方式，更符合松耦合。

缺点：

• 使得重定义Adaptee的行为较困难，这就需要生成Adaptee的子类并且使得Adapter引用这个子类而不是引用Adaptee本身。

四、使用场景

在以下情况下可以考虑使用适配器模式：

1. 系统需要复用现有类，而该类的接口不符合系统的需求
2. 想要建立一个可重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。
3. 对于对象适配器模式，在设计里需要改变多个已有子类的接口，如果使用类的适配器模式，就要针对每一个子类做一个适配器，而这不太实际。

五、.NET中适配器模式的实现

1．适配器模式在.NET Framework中的一个最大的应用就是COM Interop。COM Interop就好像是COM和.NET之间的一座桥梁（关于COM互操作更多内容可以参考我的互操作系列）。COM组件对象与.NET类对象是完全不同的，但为了使.NET程序

象使用.NET对象一样使用COM组件，微软在处理方式上采用了Adapter模式，对COM对象进行包装，这个包装类就是RCW(Runtime Callable Wrapper)。RCW实际上是runtime生成的一个.NET类，它包装了COM组件的方法，并内部实现对COM组件的调用。如下图所示：

 

2．.NET中的另外一个适配器模式的应用就是DataAdapter。ADO.NET为统一的数据访问提供了多个接口和基类，其中最重要的接口之一是IdataAdapter。DataAdpter起到了数据库到DataSet桥接器的作用，使应用程序的数据操作统一到DataSet上，而与具体的数据库类型无关。甚至可以针对特殊的数据源编制自己的DataAdpter，从而使我们的应用程序与这些特殊的数据源相兼容。

六、总结

到这里适配器模式的介绍就结束了，本文主要介绍了适配器模式的两种实现、分析它们的优缺点以及使用场景的介绍，在适配器模式中，适配器可以是抽象类，并适配器模式的实现是非常灵活的，我们完全可以将Adapter****模式中的“现存对象”作为新的接口方法参数，适配器类可以根据参数参数可以返回一个合适的实例给客户端。

本专题的所有源码：设计模式之适配器模式