代理模式(Proxy Pattern)

设计模式 - 吕震宇

.NET设计模式系列文章

薛敬明的专栏

乐在其中设计模式(C#)

C#设计模式（13）－Proxy Pattern

一、 代理（Proxy）模式

代理（Proxy）模式给某一个对象提供一个代理，并由代理对象控制对原对象的引用。

代理模式的英文叫做Proxy或Surrogate，中文都可译成"代理"。所谓代理，就是一个人或者一个机构代表另一个人或者另一个机构采取行动。在一些情况下，一个客户不想或者不能够直接引用一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。

二、 代理的种类

如果按照使用目的来划分，代理有以下几种：

• 远程（Remote）代理：为一个位于不同的地址空间的对象提供一个局域代表对象。这个不同的地址空间可以是在本机器中，也可是在另一台机器中。远程代理又叫做大使（Ambassador）。
• 虚拟（Virtual）代理：根据需要创建一个资源消耗较大的对象，使得此对象只在需要时才会被真正创建。
• Copy-on-Write代理：虚拟代理的一种。把复制（克隆）拖延到只有在客户端需要时，才真正采取行动。
• 保护（Protect or Access）代理：控制对一个对象的访问，如果需要，可以给不同的用户提供不同级别的使用权限。
• Cache代理：为某一个目标操作的结果提供临时的存储空间，以便多个客户端可以共享这些结果。
• 防火墙（Firewall）代理：保护目标，不让恶意用户接近。
• 同步化（Synchronization）代理：使几个用户能够同时使用一个对象而没有冲突。
• 智能引用（Smart Reference）代理：当一个对象被引用时，提供一些额外的操作，比如将对此对象调用的次数记录下来等。

在所有种类的代理模式中，虚拟（Virtual）代理、远程（Remote）代理、智能引用代理（Smart Reference Proxy）和保护（Protect or Access）代理是最为常见的代理模式。

三、 远程代理的例子

Achilles是一个用来测试网站的安全性能的工具软件。Achilles相当于位于客户端的的一个桌面代理服务器，在一个HTTP过程里起到一个中间人的作用，但是Achilles与通常的代理服务器又有不同。Achilles截获双向的通信数据，使得Achilles软件的用户可以改变来自和发往网络服务器的数据，甚至可以拦截并修改SSL通讯。（这点在《Java与模式》中解释的不是很清楚，关于对非对称密钥加密拦截、破解方法，可以参考我的另外一篇文章《通过代理截取并修改非对称密钥加密信息》）。

另外一个例子就是Windows的快捷方式。快捷方式是它所引用的程序的一个代理。

四、 代理模式的结构

代理模式的类图如下图所示：

代理模式所涉及的角色有：

抽象主题角色（Subject）：声明了真实主题和代理主题的共同接口，这样一来在任何使用真实主题的地方都可以使用代理主题。

代理主题（Proxy）角色：代理主题角色内部含有对真是主题的引用，从而可以在任何时候操作真实主题对象；代理主题角色提供一个与真实主题角色相同的接口，以便可以在任何时候都可以替代真实主体；控制真实主题的应用，负责在需要的时候创建真实主题对象（和删除真实主题对象）；代理角色通常在将客户端调用传递给真实的主题之前或之后，都要执行某个操作，而不是单纯的将调用传递给真实主题对象。

真实主题角色（RealSubject）角色：定义了代理角色所代表的真实对象。

五、 代理模式示例性代码

以下示例性代码实现了代理模式：

// Proxy pattern -- Structural example  
using System;

// "Subject"
abstract class Subject
{
  // Methods
  abstract public void Request();
}

// "RealSubject"
class RealSubject : Subject
{
  // Methods
  override public void Request()
  {
    Console.WriteLine("Called RealSubject.Request()");
  }
}

// "Proxy"
class Proxy : Subject
{
  // Fields
  RealSubject realSubject;

  // Methods
  override public void Request()
  {
    // Uses "lazy initialization"
    if( realSubject == null )
      realSubject = new RealSubject();

    preRequest();
    realSubject.Request();
    postRequest();
  }

  public void preRequest()
  { Console.WriteLine("PreRequest."); }

  public void postRequest()
  { Console.WriteLine("PostRequest."); }
}

/// <summary>
/// Client test
/// </summary>
public class Client
{
  public static void Main( string[] args )
  {
    // Create proxy and request a service
    Proxy p = new Proxy();
    p.Request();
  }
}

六、 高老庄悟空降八戒

尽管那时候八戒还不叫八戒，但为了方便，这里仍然这样称呼他。

高老庄的故事

却说那春融时节，悟空牵着白马，与唐僧赶路西行。忽一日天色将晚，远远地望见一村人，这就是高老庄，猪八戒的丈人高太公家。为了将高家三小姐解救出八戒的魔掌，悟空决定扮做高小姐，会一会这个妖怪：

"行者却弄神通，摇身一变，变得就如那女子一般，独自个坐在房里等那妖精。不多时，一阵风来，真个是走石飞砂……那阵狂风过处，只见半空里来了一个妖精，果然生得丑陋：黑脸短毛，长喙大耳，穿一领青不青、蓝不蓝的梭布直裰，系一条花布手巾……走进房，一把搂住，就要亲嘴……"

高家三小姐的神貌和本人

悟空的下手之处是将高家三小姐的神貌和她本人分割开来，这和"开一闭"原则有异曲同工之妙。这样一来，"高家三小姐本人"也就变成了"高家三小姐神貌"的具体实现，而"高家三小姐神貌"则变成了抽象角色，如下图所示。

悟空扮演并代替高家三小姐

悟空巧妙地实现了"高家三小姐神貌"，也就是说同样变成了"高家三小姐神貌"的子类。悟空可以扮演高家三小姐，并代替高家三小姐会见八戒，其静态结构图如下图所示。

悟空代替"高家三小姐本人"去会见猪八戒。显然这就是代理模式的应用。具体地讲，这是保护代理模式的应用。只有代理对象认为合适时，才会将客户端的请求传递给真实主题对象。

八戒分辨不出真假老婆

从《西游记》的描述可以看出，猪八戒根本份辨不出悟空扮演的"高家三小姐替身"和 "高家三小姐本人"。客户端分辨不出代理主题对象与真实主题对象，这是代理模式的一个
重要用意。

悟空代替高家三小姐会见八戒的对象图如下图所示。

七、 不同类型的代理模式

远程代理

可以将网络的细节隐藏起来，使得客户端不必考虑网络的存在。客户完全可以认为被代理的对象是局域的而不是远程的，而代理对象承担了大部分的网络通信工作，远程代理的结构图如下图所示。

虚拟代理

使用虚拟代理模式的优点就是代理对象可以在必要的时候才将被代理的对象加载。代理可以对加载的过程加以必要的优化。当一个模块的加载十分耗费资源的时候，虚拟代理的优点就非常明显。

保护代理

保护代理可以在运行时间对用户的有关权限进行检查，然后在核实后决定将调用传递给被代理的对象。

智能引用代理

在访问一个对象时可以执行一些内务处理（Housekeeping）操作，比如计数操作等。

八、 代理模式实际应用的例子

该例子演示了利用远程代理模式提供对另外一个应用程序域（AppDomain）的对象进行访问控制。

// Proxy pattern -- Real World example
using System;
using System.Runtime.Remoting;

// "Subject" 
public interface IMath
{
  // Methods
  double Add( double x, double y );
  double Sub( double x, double y );
  double Mul( double x, double y );
  double Div( double x, double y );
}

// "RealSubject" 
class Math : MarshalByRefObject, IMath
{
  // Methods
  public double Add( double x, double y ){ return x + y; }
  public double Sub( double x, double y ){ return x - y; }
  public double Mul( double x, double y ){ return x * y; }
  public double Div( double x, double y ){ return x / y; }
}

// Remote "Proxy Object" 
class MathProxy : IMath
{
  // Fields
  Math math;

  // Constructors
  public MathProxy()
  {
    // Create Math instance in a different AppDomain
    AppDomain ad = System.AppDomain.CreateDomain("MathDomain",null, null );
    ObjectHandle o = ad.CreateInstance("Proxy_RealWorld", "Math", false,
      System.Reflection.BindingFlags.CreateInstance, null, null, null,null,null );
    math = (Math) o.Unwrap();
  }

  // Methods
  public double Add( double x, double y )
  { 
    return math.Add(x,y); 
  }
  public double Sub( double x, double y )
  { 
    return math.Sub(x,y); 
  }
  public double Mul( double x, double y )
  { 
    return math.Mul(x,y); 
  }
  public double Div( double x, double y )
  { 
    return math.Div(x,y); 
  }
}
/// <summary>
///   ProxyApp test
/// </summary>
public class ProxyApp
{
  public static void Main( string[] args )
  {
    // Create math proxy
    MathProxy p = new MathProxy();

    // Do the math
    Console.WriteLine( "4 + 2 = {0}", p.Add( 4, 2 ) );
    Console.WriteLine( "4 - 2 = {0}", p.Sub( 4, 2 ) );
    Console.WriteLine( "4 * 2 = {0}", p.Mul( 4, 2 ) );
    Console.WriteLine( "4 / 2 = {0}", p.Div( 4, 2 ) );
  }
}

---

参考文献：
阎宏，《Java与模式》，电子工业出版社
[美]James W. Cooper，《C#设计模式》，电子工业出版社
[美]Alan Shalloway  James R. Trott，《Design Patterns Explained》，中国电力出版社
[美]Robert C. Martin，《敏捷软件开发－原则、模式与实践》，清华大学出版社
[美]Don Box, Chris Sells，《.NET本质论 第1卷：公共语言运行库》，中国电力出版社

.NET设计模式（14）：代理模式（Proxy Pattern）

代理模式（Proxy Pattern）

——.NET设计模式系列之十四

Terrylee，2006年5月

摘要：在软件系统中，有些对象有时候由于跨越网络或者其他的障碍，而不能够或者不想直接访问另一个对象，如果直接访问会给系统带来不必要的复杂性，这时候可以在客户程序和目标对象之间增加一层中间层，让代理对象来代替目标对象打点一切。这就是本文要说的Proxy模式。

 

主要内容

1．例说Proxy模式

2．Proxy模式效果及实现要点

……

 

概述

在软件系统中，有些对象有时候由于跨越网络或者其他的障碍，而不能够或者不想直接访问另一个对象，如果直接访问会给系统带来不必要的复杂性，这时候可以在客户程序和目标对象之间增加一层中间层，让代理对象来代替目标对象打点一切。这就是本文要说的Proxy模式。

意图

为其他对象提供一种代理以控制对这个对象的访问。

结构图

图1  Proxy模式结构图

 

生活中的例子

代理模式提供一个中介以控制对这个对象的访问。一张支票或银行存单是账户中资金的代理。支票在市场交易中用来代替现金，并提供对签发人账号上资金的控制。

 

图2  使用银行存单例子的Proxy模式对象图

Proxy模式解说

在软件系统中，我们无时不在跨越障碍，当我们访问网络上一台计算机的资源时，我们正在跨越网络障碍，当我们去访问服务器上数据库时，我们又在跨越数据库访问障碍，同时还有网络障碍。跨越这些障碍有时候是非常复杂的，如果我们更多的去关注处理这些障碍问题，可能就会忽视了本来应该关注的业务逻辑问题，Proxy模式有助于我们去解决这些问题。我们以一个简单的数学计算程序为例，这个程序只负责进行简单的加减乘除运算：

/// <summary>

/// Author : Terrylee

/// From : http://terrylee.cnblogs.com

/// </summary>

public class Math
{
    public double Add(double x,double y)
    {
        return x + y;
    }

    public double Sub(double x,double y)
    {
        return x - y;
    }

    public double Mul(double x,double y)
    {
        return x * y;
    }

    public double Dev(double x,double y)
    {
        return x / y;
    }
}

如果说这个计算程序部署在我们本地计算机上，使用就非常之简单了，我们也就不用去考虑Proxy模式了。但现在问题是这个Math类并没有部署在我们本地，而是部署在一台服务器上，也就是说Math类根本和我们的客户程序不在同一个地址空间之内，我们现在要面对的是跨越Internet这样一个网络障碍：

图3

这时候调用Math类的方法就没有下面那么简单了，因为我们更多的还要去考虑网络的问题，对接收到的结果解包等一系列操作。

/// <summary>

/// Author : Terrylee

/// From : http://terrylee.cnblogs.com

/// </summary>

public class App
{
    public static void Main()
    {
        Math math = new Math();

        // 对接收到的结果数据进行解包

        double addresult = math.Add(2,3);

        double subresult = math.Sub(2,3);

        double mulresult = math.Mul(2,3);

        double devresult = math.Dev(2,3);
    }
}

为了解决由于网络等障碍引起复杂性，就引出了Proxy模式，我们使用一个本地的代理来替Math类打点一切，即为我们的系统引入了一层间接层，示意图如下

图4

我们在MathProxy中对实现Math数据类的访问，让MathProxy来代替网络上的Math类，这样我们看到MathProxy就好像是本地Math类，它与客户程序处在了同一地址空间内：

/// <summary>

/// Author : Terrylee

/// From : http://terrylee.cnblogs.com

/// </summary>

public class MathProxy
{
    private Math math = new Math();

    // 以下的方法中，可能不仅仅是简单的调用Math类的方法

    public double Add(double x,double y)
    {
        return math.Add(x,y);
    }

    public double Sub(double x,double y)
    {
        return math.Sub(x,y);
    }

    public double Mul(double x,double y)
    {
        return math.Mul(x,y);
    }

    public double Dev(double x,double y)
    {
        return math.Dev(x,y);
    }
}

现在可以说我们已经实现了对Math类的代理，存在的一个问题是我们在MathProxy类中调用了原实现类Math的方法，但是Math并不一定实现了所有的方法，为了强迫Math类实现所有的方法，另一方面，为了我们更加透明的去操作对象，我们在Math类和MathProxy类的基础上加上一层抽象，即它们都实现与IMath接口，示意图如下：

示意性代码如下：

/// <summary>

/// Author : Terrylee

/// From : http://terrylee.cnblogs.com

/// </summary>

public interface IMath
{
    double Add(double x,double y);

    double Sub(double x,double y);

    double Mul(double x,double y);

    double Dev(double x,double y);
}

Math类和MathProxy类分别实现IMath接口：

public class MathProxy : IMath
{
    //
}

public class Math : IMath
{
    //
}

此时我们在客户程序中就可以像使用Math类一样来使用MathProxy类了：

/// <summary>

/// Author : Terrylee

/// From : http://terrylee.cnblogs.com

/// </summary>

public class App
{
    public static void Main()
    {
        MathProxy proxy = new MathProxy();

        double addresult = proxy.Add(2,3);

        double subresult = proxy.Sub(2,3);

        double mulresult = proxy.Mul(2,3);

        double devresult = proxy.Dev(2,3);
    }
}

到这儿整个使用Proxy模式的过程就完成了，回顾前面我们的解决方案，无非是在客户程序和Math类之间加了一个间接层，这也是我们比较常见的解决问题的手段之一。另外，对于程序中的接口Imath，并不是必须的，大多数情况下，我们为了保持对对象操作的透明性，并强制实现类实现代理类所要调用的所有的方法，我们会让它们实现与同一个接口。但是我们说代理类它其实只是在一定程度上代表了原来的实现类，所以它们有时候也可以不实现于同一个接口。

效果及实现要点

Proxy模式根据种类不同，效果也不尽相同：

1．远程（Remote）代理：为一个位于不同的地址空间的对象提供一个局域代表对象。这个不同的地址空间可以是在本机器中，也可是在另一台机器中。远程代理又叫做大使（Ambassador）。好处是系统可以将网络的细节隐藏起来，使得客户端不必考虑网络的存在。客户完全可以认为被代理的对象是局域的而不是远程的，而代理对象承担了大部份的网络通讯工作。由于客户可能没有意识到会启动一个耗费时间的远程调用，因此客户没有必要的思想准备。

2．虚拟（Virtual）代理：根据需要创建一个资源消耗较大的对象，使得此对象只在需要时才会被真正创建。使用虚拟代理模式的好处就是代理对象可以在必要的时候才将被代理的对象加载；代理可以对加载的过程加以必要的优化。当一个模块的加载十分耗费资源的情况下，虚拟代理的好处就非常明显。

3．Copy-on-Write代理：虚拟代理的一种。把复制（克隆）拖延到只有在客户端需要时，才真正采取行动。

4．保护（Protect or Access）代理：控制对一个对象的访问，如果需要，可以给不同的用户提供不同级别的使用权限。保护代理的好处是它可以在运行时间对用户的有关权限进行检查，然后在核实后决定将调用传递给被代理的对象。

5．Cache代理：为某一个目标操作的结果提供临时的存储空间，以便多个客户端可以共享这些结果。

6．防火墙（Firewall）代理：保护目标，不让恶意用户接近。

7．同步化（Synchronization）代理：使几个用户能够同时使用一个对象而没有冲突。

8．智能引用（Smart Reference）代理：当一个对象被引用时，提供一些额外的操作，比如将对此对象调用的次数记录下来等。

总结

在软件系统中，增加一个中间层是我们解决问题的常见手法，这方面Proxy模式给了我们很好的实现。

 

参考资料

Erich Gamma等，《设计模式：可复用面向对象软件的基础》，机械工业出版社

Robert C.Martin，《敏捷软件开发：原则、模式与实践》，清华大学出版社

阎宏，《Java与模式》，电子工业出版社

Alan Shalloway James R. Trott，《Design Patterns Explained》，中国电力出版社

MSDN WebCast 《C#面向对象设计模式纵横谈(13)：Proxy代理模式(结构型模式)》

.NET设计模式（15）：结构型模式专题总结

——探索设计模式系列之十五

Terrylee，2006年5月

摘要：结构型模式，顾名思义讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象，从而实现新的功能（对象结构型模式）。这些结构型模式，它们在某些方面具有很大的相似性，仔细推敲，侧重点却各有不同。本文试图对这几种结构型模式做一个简单的小结。

 

主要内容

1．结构型模式概述

2．结构型模式区别与比较

3．对变化的封装

 

结构型模式概述

结构型模式，顾名思义讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象，从而实现新的功能（对象结构型模式）。这些结构型模式，它们在某些方面具有很大的相似性，仔细推敲，侧重点却各有不同。

Adapter模式通过类的继承或者对象的组合侧重于转换已有的接口；Bridge模式通过将抽象和实现相分离，让它们可以分别独立的变化，它强调的是系统沿着多个方向的变化；Decorator模式采用对象组合而非继承的手法，实现了在运行时动态的扩展对象功能的能力，它强调的是扩展接口；Composite模式模糊了简单元素和复杂元素的概念，它强调的是一种类层次式的结构；Façade 模式将复杂系统的内部子系统与客户程序之间的依赖解耦，它侧重于简化接口，更多的是一种架构模式；Flyweight模式解决的是由于大量的细粒度对象所造成的内存开销的问题，它与Façade模式恰好相反，关注的重点是细小的对象；Proxy模式为其他对象提供一种代理以控制对这个对象的访问，它注重于增加间接层来简化复杂的问题。

结构型模式区别与比较

1．桥接模式与装饰模式

这两个模式在一定程度上都是为了减少子类的数目，避免出现复杂的继承关系。但是它们解决的方法却各有不同，装饰模式把子类中比基类中多出来的部分放到单独的类里面，以适应新功能增加的需要，当我们把描述新功能的类封装到基类的对象里面时，就得到了所需要的子类对象，这些描述新功能的类通过组合可以实现很多的功能组合，装饰模式的简略图如下：

图1  装饰模式简略图

桥接模式则把原来的基类的实现化细节抽象出来，在构造到一个实现化的结构中，然后再把原来的基类改造成一个抽象化的等级结构，这样就可以实现系统在多个维度上的独立变化，桥接模式的简略图如下：

图2  桥接模式简略图 

2．外观模式和代理模式

外观模式和代理模式解决问题的侧重点不同，但是它们解决问题的手法却是一样的，即都是引入了间接层的手法，这也是我们软件系统中经常用的一种手法。外观模式虽然侧重于简化接口，但是在某些情况下，外观模式也可以兼任代理模式的责任，例如外观对象有可能是另一个位于另一个地址空间对象的远程代理，这时候我们可以叫做外观代理模式，或者代理外观模式。它们的类简略图如下：

  图3  代理模式简略图

图4  外观模式简略图

3．适配器模式

适配器模式重在转换接口，它能够使原本不能在一起工作的两个类一起工作，所以经常用在类库复用，代码迁移等方面，有一种亡羊补牢的味道。类适配器和对象适配器可以根据具体实际情况来选用，但一般情况建议使用对象适配器模式，如下图所示，左边是类适配器模式，右边是对象适配器模式：

   图5  适配器模式简略图

对变化的封装

如何应对变化，是软件开发的一个永恒的主题，也许我们不能够杜绝变化的发生，但至少我们可以通过一些手段让变化降到最低。“找到系统可变的因素，将之封装起来”，通常就叫做对变化的封装。关于这个问题的解释在《Java与模式》中讲的很清晰，抽象化与实现化的简单实现，也就是“开-闭”原则在类层次上的最简单实现，如下图所示：

图6

在这个继承结构中，第一层是抽象化，它封装了抽象的业务逻辑，这是系统中不变的部分；第二层是实现化，它是具体的业务逻辑的实现，封装了系统中变化的部分，这个实现允许实现化角色多态性的变化：

图7

也就是说，客户端依赖的是业务逻辑的抽象化类型的对象，而与抽象化的具体实现无关，不在乎它到底是“实现化”，“实现化2”还是“实现化3”，如下图所示：

图8

每一种继承关系都封装了一个变化因素，而一个继承关系不应当处理两个变化因素，换言之，这种简单继承关系不能处理抽象化与实现化都变化的情况，如下图所示：

图9

上图中的两个变化因素应当是独立的，可以在不影响另一者的情况下独立的变化，如下面这两个等级结构分别封装了自己的变化因素，由于每一个变化因素都是可以通过静态关系表达的，因此分别使用继承关系实现，如下图：

图10

在抽象化和实现化之间的联系怎么办呢？好的设计只有一个，不好的设计却有很多中，下面这种设计就是继续使用继承进行静态关系设计的类图：

图11

这样的设计其实存在着很多的问题，首先出现的是多重的继承关系，随着具体实现化的增多，子类的继承关系会变得异常复杂；其次如果出现新的抽象化修正或者新的具体实现角色，就只好重新修改现有系统中的静态关系，以适应新的角色，这就违背了开放-封闭原则。正确是设计应该是使用两个独立的等级结构封装两个独立的变化因素，并在它们之间使用聚合关系，以达到功能复用的目的，这就回到了我们的桥接模式上，如下图所示：

图12

从另一个角度讲，一个好的设计通常没有多于两层的继承等级结构，或者说，如果出现两个以上的变化因素，就需要找出哪一个因素是静态的，可以使用静态关系，哪一个是动态的，必须使用聚合关系。

 

更多的设计模式文章可以访问《.NET设计模式系列文章》

 

参考资料

Erich Gamma等，《设计模式：可复用面向对象软件的基础》，机械工业出版社

Robert C.Martin，《敏捷软件开发：原则、模式与实践》，清华大学出版社

阎宏，《Java与模式》，电子工业出版社

Alan Shalloway James R. Trott，《Design Patterns Explained》，中国电力出版社