代理模式的目地是为对象提供一种代理以控制对这个对象的访问。为什么会出现“通过一个代理对象，控制其他对象访问目标对象”这种场景，而不知直接new()出一个对象直接使用呢？这是因为在有些场景下对象的访问比较复杂，且需要一些额外的控制，这时如果直接new()出实例，并在调用端处理这些繁杂的细节，会增加系统的耦合。类似的场景有很多，比如远程访问、数据库访问、权限校验、负载均衡等等。
GOF对外观模式的描述为：
Provide a surrogate or placeholder for another object to control accessto it...
— Design Patterns : Elements of Reusable Object-Oriented Software
UML类图:
代理类本身也实现了ISubject接口，但在具体调用时，它会把请求转向一个RealSubject对象进行真正的处理。
代码实现:
public interface ISubject
{
string Request();
}
public class RealSubject : ISubject
{
public string Request()
{
return "From real subject";
}
//这里使用Singleton的目地是模拟复杂性，比如客户程序并不知道如何使用远端的具体类型
private static ISubject singleton = new RealSubject();
private RealSubject() { }
public static ISubject GetInstance()
{
return singleton;
}
}
public class Proxy : ISubject
{
public string Request()
{
//预处理
var result= RealSubject.GetInstance().Request();
//后处理
return result;
}
}
在代码示例中，使用Singleton模拟对象访问的复杂性，然后使用代理封装了这种复杂性，同时对访问的控制可以在预处理、后处理的部分扩展。
使用代理对象需要注意的几个问题
- 引入代理对象并不应该增加客户程序的复杂性，按照依赖倒置的原则，客户程序需要知道的也只是目标对象的抽象接口，因此相应的代理对象也就应该实现这个接口，否则等于变相向客户程序引入新的复杂性。
- 代理的目的是控制客户程序对目标对象的访问，因此代理必须可以直接或间接地知道目标类型在哪，以及如何访问。
- 代理类不必知道具体的目标类型，很多时候它只要能够按照与客户程序统一的约定，提供一个具有抽象特征的类型即可，代理类也只依赖抽象类型，至于具体目标类型，可以组合使用创建型模式来实现。
代理模式的优点
- 职责清晰，具体目标类型只需要实现实际的业务逻辑，而不用关心其他非本职责的事务，通过后期的代理完成这些事务，附带的结果就是编程简洁清晰。
- 代理对象可以在客户端和目标对象之间起到中介的作用，起到保护目标对象的作用。
- 高扩展性。
代理模式的缺点
- 代理模式会造成系统设计中类的数目的增加。
- 由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。
- 增加了系统的复杂度。
参考书籍：
王翔著 《设计模式——基于C#的工程化实现及扩展》