设计模式（四）——代理模式(Proxy)

标签：完全   函数参数   开始   更换   通过   console   oid   pre   设计   

代理模式的参与者有：一个约束、一个代理者、一个被代理者、一个调用者

代理模式的实现很简单；还是那个房子，对于开门这个操作，我更换了一个远程解锁的门，那么我就可以通过这个远程连接的服务器远程解锁，这样我家里人没带钥匙，我也可以远程解锁了，而且不需要钥匙，甚至完全不需要知道锁的存在，我代码实现一下

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

设计模式（四）——代理模式(Proxy)

标签：完全   函数参数   开始   更换   通过   console   oid   pre   设计   

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