设计模式（四）——代理模式(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、关注点不一样，代理模式关注的是控制对真正业务对象的访问，装饰器模式关注的是在一个对象上动态的添加方法。

原文地址：https://www.cnblogs.com/yuchenghao/p/11980521.html