为什么要控制对于某个对象的访问呢?举个例子:有这样一个消耗大量系统资源的巨型对象,你只是偶尔需要使用它, 并非总是需要。
你可以实现延迟初始化:在实际有需要时再创建该对象。对象的所有客户端都要执行延迟初始代码。不幸的是,这很可能会带来很多重复代码。
在理想情况下,我们希望将代码直接放入对象的类中,但这并非总是能实现:比如类可能是第三方封闭库的一部分。
代理模式建议新建一个与原服务对象接口相同的代理类,然后更新应用以将代理对象传递给所有原始对象客户端。代理类接收到客户端请求后会创建实际的服务对象,并将所有工作委派给它。
这有什么好处呢?如果需要在类的主要业务逻辑前后执行一些工作,你无需修改类就能完成这项工作。由于代理实现的接口与原类相同,因此你可将其传递给任何一个使用实际服务对象的客户端。
代理模式结构:
类比真实世界:
信用卡是银行账户的代理,银行账户则是一大捆现金的代理。它们都实现了同样的接口,均可用于进行支付。消费者会非常满意,因为不必随身携带大量现金;商店老板同样会十分高兴,因为交易收入能以电子化的方式进入商店的银行账户中,无需担心存款时出现现金丢失或被抢劫的情况。
(1)模式动机
在面向对象系统中,有些对象由于某种原因(比如对象创建的开销很大,或者某些操作需要安全控制,或者需要进程外的访问等)直接访问会给使用者或系统结构带来很多麻烦。
如何在不失去透明操作(一致性)对象的同时来管理/控制这些对象特有的复杂性?增加一层间接层是软件开发中常见的解决方式。
(2)模式定义
为其他对象提供一种代理以控制(通过隔离、使用接口)对这个对象的访问。
(3)要点总结
a). “增加一层间接层”是软件系统中对许多复杂问题的一种常见解决方法。在面向对象系统中,直接使用某些对象会带来很多问题,作为间接层的 proxy 对象便是解决这一问题的常用手段。
b). 具体proxy设计模式的实现方法、实现粒度都相差很大,有些可能对单个对象做细粒度的控制,如copy-on-write技术,有些可能对组件模块提供抽象代理层,在架构层次给对象做proxy。
c). Proxy并不一定要求保持接口完整的一致性,只要能够实现间接控制,有时候损及一些透明性是可以接受的。
未使用代理模式时,代码如下
class ISubject{
public:
virtual void process();
};
class RealSubject : public ISubject{
public:
virtual void process();
};
class ClientApp{
ISubject* subject;
public:
ClientApp(){
subject = new RealSubject(); //直接访问主体
}
void DoTask(){
//...
subject->process();
//...
}
};
使用了代理模式的代码如下,通过代理来间接访问主体,代码类图如下
class ISubject{
public:
virtual void process();
};
class SubjectProxy : public ISubject{
public:
virtual void process(){
//对RealSubject的一种间接访问
}
};
class ClientApp{
ISubject* subject;
public:
ClientApp(){
subject = new SubjectProxy(); //间接访问主体,用proxy和不用看起来都很透明(很相似)
}
void DoTask(){
//...
subject->process();
//...
}
};