代理模式通过引入代理对象控制对真实对象的访问，可在不修改真实对象的前提下添加日志、权限、缓存等额外逻辑，常见于懒加载、权限控制、远程调用和日志记录等场景。
代理模式，简单来说，就是给一个对象提供一个替身或者占位符，来控制对这个对象的访问。它不是直接操作那个真实的对象，而是通过这个“替身”来间接进行。这个替身可以做很多事情，比如在你真正需要那个对象的时候才去创建它，或者在访问前做些权限检查，甚至可以记录日志、缓存结果等等。它就像一个中间人，帮你把一些额外的逻辑和真实对象的核心业务分离开来。
解决方案
代理模式的核心思想在于引入一个代理对象，这个代理对象和它所代表的真实对象实现相同的接口。这样，客户端代码在调用时，无需知道它面对的是真实对象还是代理对象，因为它们对外提供的接口是一致的。代理对象内部会持有一个真实对象的引用，并在适当的时候将请求转发给真实对象处理。
这种模式的妙处在于，你可以在不修改真实对象代码的前提下，为真实对象的功能添加额外的行为。这就像给一个黑盒子外面套了个透明的盒子，透明的盒子可以观察、过滤、甚至延迟内部黑盒子的操作，但黑盒子本身的运作逻辑是保持不变的。
代理模式通常包含以下几个角色：
Subject（抽象主题）： 定义了真实对象和代理对象共同实现的接口，客户端通过这个接口来访问对象。RealSubject（真实主题）： 实现了Subject接口，是代理对象所代表的真实对象，负责执行具体的业务逻辑。Proxy（代理）： 也实现了Subject接口，并持有一个RealSubject的引用。它负责控制对RealSubject的访问，并在转发请求给RealSubject之前或之后执行一些附加操作。
通过这种方式，代理模式提供了一种结构化的方法来管理和增强对象之间的交互，使得系统更加灵活、可维护。
代理模式有哪些常见的应用场景？
代理模式在实际开发中简直无处不在，很多时候我们用了可能都没意识到这就是代理。它能解决不少实际问题，比如性能优化、安全控制、远程调用封装等等。
首先想到的就是懒加载（Virtual Proxy）。想象一下，你有一个超级大的图片库应用，或者需要加载一个非常耗时的报表数据。如果一启动就把所有图片或数据都加载到内存里，那用户体验肯定很糟糕，应用会卡死。代理模式就能在这里发挥作用：你创建一个图片代理对象，它只在用户真正滚动到那张图片、或者点击了“查看报表”按钮时，才去加载真实的图片数据或生成报表。这样就大大节省了启动时间和内存开销，用户会觉得应用响应很快。
再来就是权限控制（Protection Proxy）。在很多企业级应用里，不是所有人都能访问所有功能的。比如一个管理后台，只有管理员才能删除用户，普通员工就只能查看。你可以在删除用户的方法前面加一个代理，代理会先检查当前用户的权限。如果权限不够，直接拒绝操作，连真实的服务方法都不会被调用。这比在业务逻辑里到处写权限判断要优雅得多，也更安全。
还有远程调用（Remote Proxy）。在分布式系统或者微服务架构里，一个服务可能需要调用另一个部署在不同服务器上的服务。直接进行网络通信、序列化反序列化这些细节是很复杂的。这时候，代理模式就派上用场了。你可以创建一个远程服务的本地代理，它看起来就像一个普通的本地对象，你直接调用它的方法。而代理的内部，会负责处理所有底层的网络通信、数据传输、错误处理等复杂逻辑，让你感觉就像在调用本地方法一样简单。
最后，别忘了日志记录和缓存（Smart Reference/General Proxy）。假设你的某个服务方法经常被调用，而且每次调用都需要执行一些耗时的计算。你可以用一个代理来包裹它，代理在第一次调用后把结果缓存起来，后续相同的请求就直接从缓存返回，避免重复计算。或者，你希望每次调用某个关键业务方法时都记录下操作日志，比如谁在什么时候调用了什么方法，代理也能很方便地帮你实现，而不需要修改原始的业务代码。这些都是在不侵入核心业务逻辑的前提下，通过代理添加额外功能的好例子。
代理模式与装饰器模式有何不同？
代理模式和装饰器模式，这两个设计模式经常让人搞混，因为它们在结构上确实有些相似：都涉及到一个“包装”的概念，即一个对象包裹着另一个对象，并且都实现了相同的接口。但它们的核心意图和解决的问题是截然不同的。
代理模式的核心意图是控制访问。它提供了一个替身，这个替身的主要职责是管理或限制对真实对象的访问。这个“管理”可能包括延迟加载、权限验证、远程调用封装、或者记录访问日志等。代理不改变真实对象的行为，它更多的是在真实对象被访问的“前”或“后”做一些事情，或者决定“是否”允许访问。你可以把代理想象成一个安全门卫，他决定谁能进入大楼，什么时候进入，以及进入时需要登记什么信息。大楼（真实对象）本身的功能并没有改变，只是进入的流程受到了控制。
而装饰器模式的核心意图是动态地增加对象的行为和职责。它允许你给一个对象添加新的功能，而不需要修改其原始代码。装饰器模式的目的是扩展对象的功能，而不是控制对它的访问。比如，你有一个基础的咖啡对象，你想给它加牛奶、加糖、加巧克力。每加一种配料，咖啡就多了一种新的“行为”或“属性”。装饰器就是用来实现这种“叠加”式的功能扩展的。它就像是给你的咖啡杯外面套了一个保温套，或者加了一个把手，让咖啡杯（真实对象）有了新的功能，但它本身仍然是咖啡杯。
所以，虽然两者都涉及包装和接口一致性，但代理是关于“访问控制”或“替身管理”，而装饰器是关于“功能扩展”。一个更侧重于管理真实对象的生命周期和访问方式，另一个则侧重于在不改变原有类的基础上，为对象添加新的能力。理解这一点，就能清晰地区分它们了。
如何用代码实现一个代理模式？
我们来用一个简单的Java例子，模拟一个用户服务，并为其添加一个日志代理。
假设我们有一个
UserService
接口，定义了获取用户名的功能。
// 抽象主题：定义了真实对象和代理对象共同实现的接口interface UserService { String getUserName(int id);}// 真实主题：实现了UserService接口，是代理对象所代表的真实对象class RealUserService implements UserService { @Override public String getUserName(int id) { System.out.println("DEBUG: 正在从数据库获取用户ID: " + id + " 的信息..."); // 模拟一个耗时操作，比如数据库查询 try { Thread.sleep(500); } catch (InterruptedException e) { Thread.currentThread().interrupt(); System.err.println("WARN: 线程被中断，获取用户失败。"); } return "用户-" + id + " (真实数据)"; }}// 代理：实现了UserService接口，并持有一个RealUserService的引用class LoggingUserServiceProxy implements UserService { private RealUserService realUserService; // 代理持有真实对象的引用 // 构造函数，传入真实对象 public LoggingUserServiceProxy(RealUserService realUserService) { this.realUserService = realUserService; } @Override public String getUserName(int id) { // 在调用真实方法之前，执行附加操作（比如记录日志） System.out.println("LOG: 请求开始 - 尝试获取用户ID " + id + " 的信息..."); // 将请求转发给真实对象处理 String userName = realUserService.getUserName(id); // 在调用真实方法之后，执行附加操作（比如记录结果） System.out.println("LOG: 请求结束 - 成功获取用户ID " + id + " 的信息: " + userName); return userName; }}// 客户端代码：如何使用代理public class ProxyPatternClient { public static void main(String[] args) { System.out.println("--- 场景一：直接调用真实服务 ---"); // 客户端直接使用真实对象 UserService directService = new RealUserService(); String user1 = directService.getUserName(101); System.out.println("客户端收到: " + user1 + "n"); System.out.println("--- 场景二：通过代理调用服务 ---"); // 客户端通过代理对象来调用服务 // 注意，客户端仍然是面向UserService接口编程，它不知道背后是真实对象还是代理 UserService proxyService = new LoggingUserServiceProxy(new RealUserService()); String user2 = proxyService.getUserName(202); System.out.println("客户端收到: " + user2 + "n"); // 再次通过代理调用，验证代理的通用性 String user3 = proxyService.getUserName(303); System.out.println("客户端收到: " + user3 + "n"); }}
运行这段代码，你会看到这样的输出：
--- 场景一：直接调用真实服务 ---DEBUG: 正在从数据库获取用户ID: 101 的信息...客户端收到: 用户-101 (真实数据)--- 场景二：通过代理调用服务 ---LOG: 请求开始 - 尝试获取用户ID 202 的信息...DEBUG: 正在从数据库获取用户ID: 202 的信息...LOG: 请求结束 - 成功获取用户ID 202 的信息: 用户-202 (真实数据)客户端收到: 用户-202 (真实数据)LOG: 请求开始 - 尝试获取用户ID 303 的信息...DEBUG: 正在从数据库获取用户ID: 303 的信息...LOG: 请求结束 - 成功获取用户ID 303 的信息: 用户-303 (真实数据)客户端收到: 用户-303 (真实数据)
从输出中可以清楚地看到，当通过
LoggingUserServiceProxy
调用
getUserName
方法时，在真实的用户获取逻辑执行前后，都会有额外的日志信息打印出来。而客户端代码在调用
proxyService.getUserName(id)
时，它只知道自己在调用一个
UserService
接口的方法，并不知道背后有一个代理在帮忙处理日志。这正是代理模式的精髓所在：在不修改
RealUserService
的情况下，为其添加了额外的功能，并且对客户端透明。这种分离关注点的做法，让代码变得更干净、更易于维护。
以上就是什么是代理模式？Proxy的实现的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1517222.html
微信扫一扫 
支付宝扫一扫 
