大家好，这里是每周都会和大家一起进步的站长~

其实也不是每周上周还是晴天~真的进步不了.....本周我们继续之前搁置了一段时间的设计模式系列

上次，我们分享了责任链模型在文章的最后，我们提到了装饰者模型两者虽然结构相似，但用途不同，装饰者模型本身就是代理者模型的特殊应用所以在本文中，我们会先学习agent模型的组成和用法，然后学习decorator

看过我文章的同学可能发现，虽然教材把设计模式分为构造型，结构型，行为型三个部分，但我并没有按照这个大纲展开内容，而是更加注重连续性，尽可能从一个模式引向另一个模式所以，在学习了流程开发的三大利器——模板，策略和责任链之后，我们就把其他行为模型放在一边，学习两个结构模型——agent和decorator

什么是代理模式。

Agent模式是一种结构化设计模式代理控制对原始对象的访问，并允许在请求提交给原始对象之前和之后进行一些处理，从而增强原始对象的逻辑处理

上述代理一般称为代理对象或直接称为proxy — Proxy，用于逻辑处理的原始对象通常称为服务对象代理要实现和服务对象相同的接口，让客户端分不清是代理还是真实的服务对象，这样代理就可以在客户端没有察觉的情况下增强服务对象的处理逻辑

增强处理逻辑是什么意思或者换一种说法，给核心功能增加增强功能比如API Handler，处理客户端对用户订单信息的查询，是核心的处理逻辑，增强的逻辑是指在查询订单信息之前，我们需要验证请求是否为有效用户，记录请求的参数和返回的响应数据等等

看了上面对代理模式的解释，你可能还是觉得有点宽泛下面我们写一个简单的代码例子在这个过程中，你几乎会发现:诶，原来这就是代理模式我写代码的时候早就用过了~！让我们一起来打开这个例子

代理模式用法演示

假设有一个表示汽车的汽车类型。

typeCarstruct

汽车的主要行为是可以驾驶，所以Car需要实现一个表示驾驶行为的接口Vehicle，这个接口Vehicle只有一个方法drive。

Car的结构指针通过实现驱动方法来实现车辆接口。

现在，我们只需要实例化car的一个实例，并在实例上调用Drive方法来驱动Car但是，如果我们的司机还是未成年人，世界上大多数国家都不允许开车开车的时候想给司机加个年龄限制怎么办

在汽车结构中加入年龄字段显然是不合理的，因为我们要表示的是驾驶员的年龄，而不是车龄同样，也不应该在Car实现的驱动方法中加入对司机年龄的判断，这样会导致每个实现车辆接口的类型在自己的驱动方法中加入一个类似的判断

此时，通常的做法是添加一个指示驱动程序类型的驱动程序。

typeDriverstructAgeint

然后是包装驱动程序和车辆类型的包装器类型。

这样，我们就可以使用包装类型将驾驶员的年龄限制添加到车辆属性的驾驶行为中。

func driveIFC . driver . age gt，=16c.vehicle.Driveelsefmt。Println

相信大家在平时的开发中都用过这个编程技巧，这其实就是代理模式。

现在，我们扩展汽车类型的驾驶行为，通过代理模式检查驾驶员的行为让我们执行程序来试试效果

正如执行后的结果所示，我们不必为服务对象—汽车类型添加任何属性和方法相反，我们只是在上面的代理层中把客户端驱动方法的调用委托给其车辆属性的驱动方法，加上之前的年龄检查行为，就可以达到想要的效果

看了例子，相信大家都明白写代码的时候怎么用代理模式了让我们走出代码，更清楚地描述代理模式的整体结构

看清代理模式。

根据上面开头的描述和下面的代码示例，我们得出代理模式涉及四个角色:客户端，服务接口，服务类和代理类。它们之间的关系由UML类图表示如下:

代理模式— UML类图

上面的UML类图中有四个角色，这四个角色在代理模式下的职责是。

该服务声明由服务类实现的接口类的业务处理逻辑是在这里定义的接口方法中实现的，代理类必须遵循这个接口将自己伪装成服务对象

如上所述，类是提供实际业务逻辑的原始对象。

类包含一个服务对象作为成员变量在代理完成其任务后)，它会将请求传递给服务对象通常代理会对其服务对象的全生命周期进行管理来增强服务对象，这样与核心业务逻辑无关的增强逻辑就可以由代理来实现

客户端通过统一的接口与服务或代理进行交互，所以服务对象的代理可以在所有需要服务对象的代码中使用，客户端根本不会察觉到。

代理模式扩展

在代理模式中，通过使代理类实现与服务类相同的接口，代理类被伪装成服务类当客户端请求代理时，代理会将请求委托给它持有的真实服务类在委托的过程中，我们可以添加增强的逻辑

如果我们把代理类当做服务对象，给代理类添加一个代理，代理的代理添加一个代理，那么就变成了另一种设计模式——装饰者模式事实上，装饰模式本身是代理模式的一个特殊应用我们稍后将研究装饰器的内容