躲不过设计模式的坑之代理模式

​哈喽，大家好，我是指北君。又是全新的一天，从一起进步开始，先来段向上语录，共勉。

创新互联是一家专业提供丛台企业网站建设,专注与成都网站建设、网站建设、H5建站、小程序制作等业务。10年已为丛台众多企业、政府机构等服务。创新互联专业的建站公司优惠进行中。

不一定努力就会有回报，但坚持是成功的另一个名字。

前言

设计模式在我看来更像是一种设计思维或设计思想，它就像《孙子兵法》一样，为你的项目工程提供方向，让你的项目工程更加健壮、灵活，延续生命力。本文即将分享的是设计模式的其中一种：代理模式。

​代理模式

• 通用官方定义：代理模式（Proxy Pattern) 是一种结构型设计模式，通过代理对象控制对原对象的访问，并允许在访问前或访问后做一些处理。
•  简单理解就是给一个对象找了一个替代品，这个替代品得到原对象授权，可以拦截一些无效或低效的访问，从而使得原对象可以释放时间做自己的事情。这样替代品实现了自己价值，原对象也得到了解放，两全其美的选择！！
•  代理主要分为以下几种类型

 静态代理：仅用于单个接口实现类，程序运行前已经存在。调用时需要传入具体实例，调用方可以直接获取具体实例。

动态代理：可以服务多个接口实现类，可以在程序运行时，通过反射机制动态创建代理对象。​

使用场景

既然这么说了，那就结合实际介绍几个，还不是轻松拿捏~

• 场景一：作为一个气血方刚的男青年，汽车总是绕不开的话题，那就先以汽车为例。

4s店或汽车厂家均可以出售汽车，对于购车消费者来说，可以直接去喜欢的汽车店去体验成品，不必跋山涉水的跨省或跨市去汽车厂家。有了4S店代理，可以节省消费者时间，更快体验到心仪的汽车，最终也是通过汽车厂家拿到成品；同时汽车工厂通过这些代理，可以更快售出汽车，可谓是一举两得。关系类图如下：

• 场景二：上面讲述的是静态代理的案例，再来一个最近实践的动态代理需求场景。

人力业务平台接入了不同客户，同时为了满足客户不同的接入需求，采用动态代理模式会为每个客户动态生成代理对象，比如需要提取客户A的简历数据，根据客户A的标识获取代理类并执行对应的实现逻辑，从而获取客户A的数据信息。关系如下

​代码分析

•  结合上述动态代理业务场景，按照UML类型进行代码设计，来演示下整体过程。首先将数据提取接口（IHandlerService）抽象出来，同时提供一个通用实现（HandlerServiceImpl）。

/*
 * 通用接口
 * */
public interface IHandlerService {


    /*
     * 抽取数据
     * */
    void handle();


    /**
     * 打印内容
     *
     * @param content 输出内容
     */
    String print(String content);


    /**
     * 设置信息
     *
     * @param prefix 信息前缀
     */
    void setPrefix(String prefix);
}


/*
 * 通用实现
 * */
@Service
public class HandlerServiceImpl implements IHandlerService {


    /*
     * 默认信息前缀
     * */
    private String prefix = "default";


    @Override
    public void handle() {
        System.out.println("=======自定义实现类" + prefix + "======");
    }


    @Override
    public String print(String content) {
        System.out.println(prefix + " 实现类输出 -》" + content);
        return prefix + "success";
    }


    @Override
    public void setPrefix(String prefix) {
        this.prefix = prefix;
    }
}

• 接下来创建个代理类，变量包含通用接口，也可以增加业务所需的其它变量。（java动态代理核心内容：InvocationHandler接口和Proxy类，代理对象在执行函数时，会通过InvocationHandler接口的invoke调用执行函数）具体代码如下：

public class MultiDynamicProxy implements InvocationHandler {

    /**
     * @see InvocationHandler
     * 每个代理实例的调用处理程序必须实现的接口，当通过代理实例调用方法时，
     * 这个方法的调用会被转发至实现InvocationHandle接口类的invoke方法去执行
     */
    private static Map map = new HashMap<>();
    public static String key = "default";

    private void addElements(String key) {
        if (map.containsKey(key)) return;
        IHandlerService handlerService = new HandlerServiceImpl();
        handlerService.setPrefix(key);
        map.put(key, handlerService);
    }

    public static IHandlerService newInstance(IHandlerService handlerService) {
        MultiDynamicProxy handlerProxy = new MultiDynamicProxy(handlerService);
        // 抽象逻辑接口
        Class handlerServiceClass = IHandlerService.class;

        /**
         *  param1：指定接口（interface）的类加载器，用于装入定义的代理类
         *  param2：动态代理类要实现的接口
         *  param3：将执行的代理方法调用派发给代理类（程序）
         * */
        return (IHandlerService) Proxy.newProxyInstance(handlerServiceClass.getClassLoader(),
                new Class[]{handlerServiceClass}, handlerProxy);
    }

    public MultiDynamicProxy(IHandlerService handlerService) {
        map.put(key, handlerService);
    }
    
    /*
     * 自定义实现类对象替换代理类对象，并执行
     * param1：proxy 方法被调用的代理实例，即真实的代理对象
     * param2：method 代理对象的method对象
     * param3：args 代理对象方法传递的参数
     * */
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        System.out.println("=====代理类执行====" + proxy.getClass().getSimpleName());
        Object invoke = method.invoke(getElement(), args);
        return invoke;
    }

    private IHandlerService getElement() {
        if (null == map.get(key)) {
            addElements(key);
        }
        return map.get(key);
    }

• 小编在每个环节都增加了日志输出，就很容易理解每个环节都做了哪些处理，日志内容请接着往下看

public static void main(String[] args) {
        IHandlerService handlerService = MultiDynamicProxy.newInstance(new HandlerServiceImpl());
        String s = handlerService.print("客户A");
        System.out.printf("执行结果 => " + s);
    }
    // 输出结果 
    // =====代理类执行====$Proxy0
    // default 实现类输出 -》客户A
    // 执行结果 => defaultsuccess

• 观察结果可以看出，执行的service实例确实为代理对象（$Proxy0），后续可以动态接入客户实现，并注册到客户信息集合，当然，也可以对实现类进行扩展，但考虑到通用性，所以接口职责尽可能保持单一，避免业务交叉，造成后续的维护困难。

总结

以上就是本文所分享的全部内容，静态代理部分由于相对比较简单，就没写代码，主要是动态代理，理解上比较容易，但是具体的执行过程确实需要仔细分析，才能明白其实现原理。

代理模式确实对于目标对象有保护作用，也方便了目标对象的扩展，但凡事都有两面性，它也不是完美的，由于多了代理层，请求处理增加处理过程，进而会降低响应速度，同时也增加了系统复杂性，维护成本会有些增加。

没有最完美的设计模式，只有最适合业务场景的设计模式。

当前文章：躲不过设计模式的坑之代理模式
标题URL：http://www.gawzjz.com/qtweb/news23/207023.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联