设计模式(四)——代理模式(Proxy)
代理模式的参与者有:一个约束、一个代理者、一个被代理者、一个调用者
代理模式的实现很简单;还是那个房子,对于开门这个操作,我更换了一个远程解锁的门,那么我就可以通过这个远程连接的服务器远程解锁,这样我家里人没带钥匙,我也可以远程解锁了,而且不需要钥匙,甚至完全不需要知道锁的存在,我代码实现一下
/// <summary> /// 抽象接口 用来进行约束 /// </summary> public interface IAccess { void Access(); } /// <summary> /// 用户类 /// </summary> public class Room : IAccess { /// <summary> /// 进入房子操作 /// </summary> public void Access() { Console.WriteLine("进房子了"); } } /// <summary> /// 远程开门类 /// </summary> public class RemoteDoor : IAccess { private Room room = new Room(); /// <summary> /// /// </summary> public void Access() { room.Access(); } }
这样我就可以通过调用
RemoteDoor类的Access()方法来间接调用Room类的Access()方法了,这种实现看起来很鸡肋哈,我为什么不直接调用Room类的方法呢,非要绕一层,这不是有病吗?
刚开始我也这么想来着,但是仔细一想,如果我们不想要调用者知道有Room这个类,或者说,这个类我不希望调用者能直接访问这个类,那这个代理模式的好处就凸显出来了;
好处: 1、隐藏了对象的位置,在对象的引入有了一定的间接性;
2、可以提供一种copy-on-write(写时复制)的优化方式,没用过,准备找个时间仔细了解一下再说。
3、可以进行一些类似AOP的操作,比如计数之类的非主线业务需求
看完代理模式之后感觉代理模式和装饰器模式好像啊,但是这两者还是有区别的,
区别:1、代理模式无需实例化真正业务对象,只需要实例化代理者的对象即可,对于调用者而言,真正的业务对象是不可知的;而装饰器模式需要实例化真正的业务对象,然后通过装饰者的构造函数参数传递这个对象,在运行时递归的被构造,此时业务对象是明朗的;
2、关注点不一样,代理模式关注的是控制对真正业务对象的访问,装饰器模式关注的是在一个对象上动态的添加方法。