古法编程: 代理模式

在软件工程的架构设计中，代理模式（Proxy Pattern） 是一种至关重要且应用广泛的结构性设计模式。它核心旨在为其他对象提供一种代理以控制对这个对象的访问，从而在不改变原始对象代码的前提下，增加额外的功能逻辑或访问控制。这种模式在实际开发中扮演着“中间人”的角色，广泛应用于远程调用、权限校验、延迟加载以及日志记录等场景。通过引入代理层，开发者可以实现客户端与真实主题之间的解耦，提升系统的灵活性和可维护性。本文将结合经典的业务场景案例，深入剖析代理模式的结构组成、代码实现细节以及其与装饰器模式的区别，帮助读者全面掌握这一经典设计思想，并在实际项目中合理运用以优化系统架构。

代理模式的核心概念与应用场景

代理模式属于结构型设计模式，其主要目的是通过创建一个代理对象来代表另一个对象，从而控制对原对象的访问。这种控制可以体现在多个方面，例如在访问真实对象之前进行权限检查、在访问之后记录日志、或者在网络通信中处理远程调用的复杂性。在许多企业级应用中，直接访问某些资源可能成本高昂或存在安全风险，此时代理模式便成为了解决这些问题的理想方案。

为了更直观地理解代理模式，我们可以将其类比生活中的中介行为。假设有一位追求者希望向心仪的对象表达爱意，但由于种种原因（如害羞、距离远或身份限制），他无法直接出面，于是委托一位好友作为代理人去执行送礼物的行为。在这个场景中，好友就是“代理”，追求者是“真实主题”，而送礼物这一行为则是双方共同实现的接口。代理不仅转达了真实主题的意图，还可以在转达过程中加入自己的逻辑，比如观察对方的反应或记录互动的次数。

值得注意的是，代理模式与装饰器模式（Decorator Pattern） 虽然结构相似，但侧重点不同。装饰器模式主要关注于动态地给一个对象添加一些额外的职责，强调功能的扩展和组合；而代理模式则侧重于控制对对象的访问，强调的是访问的控制权和间接性。在实际编码中，如果目的是增强功能，通常选择装饰器；如果目的是控制访问或管理生命周期，则应选择代理模式。

代理模式的结构组成

代理模式通常包含三个核心角色，它们通过统一的接口进行交互，确保了客户端可以透明地使用代理对象或真实对象。

抽象主题（Subject）

抽象主题定义了真实主题和代理主题共同的接口。在任何使用真实主题的地方，都可以使用代理主题，因为两者实现了相同的接口。这一层是代理模式实现透明性的关键，它确保了客户端无需关心背后是真实对象还是代理对象。在Java中，这通常表现为一个接口或抽象类，声明了所有需要被代理的方法。

真实主题（RealSubject）

真实主题是代理所代表的真实对象，它是最终执行具体业务逻辑的实体。真实主题包含了核心业务功能的实现，但它对客户端可能是不可见的，或者访问受到限制。在代理模式中，真实主题专注于完成其本职工作，而不必关心访问控制、日志记录等非核心逻辑，这符合单一职责原则。

代理（Proxy）

代理持有对真实主题对象的引用，从而可以在任何时候操作真实主题对象。代理对象提供了与真实主题相同的接口，以便在任何时候都能替代真实主题。代理通常在将请求转发给真实主题之前或之后执行一些额外的操作，如初始化、权限验证、缓存检查或日志记录。在某些情况下，代理还负责创建和销毁真实主题对象，从而实现懒加载或资源管理。

基于业务场景的代码实现

为了深入展示代理模式的实现细节，我们将通过一个具体的业务场景进行代码演示。场景设定为：一位名为“卓贾”的追求者希望通过代理“戴励”向“李娇娇”赠送礼物。代理人在执行送礼动作时，会记录互动次数，并在达到一定条件时触发特定的业务逻辑（如情感变化）。

定义抽象主题接口

首先，我们需要定义一个统一的接口 IGiveGift，该接口规定了所有送礼行为的标准方法。无论是真实的追求者还是代理人，都必须实现这个接口，以保证行为的一致性。

public interface IGiveGift {
    /**
     * 赠送洋娃娃
     */
    void giveDolls();

    /**
     * 赠送鲜花
     */
    void giveFlowers();

    /**
     * 赠送巧克力
     */
    void giveChocolate();
}

在上述代码中，IGiveGift 接口定义了三个核心方法：giveDolls、giveFlowers 和 giveChocolate。这些方法代表了具体的业务行为。通过面向接口编程，客户端代码只需依赖 IGiveGift 接口，而无需关心具体的实现类是 Pursuit 还是 MyProxy，这极大地提高了代码的可扩展性和可测试性

实现真实主题类

接下来，我们实现真实主题类 Pursuit，它代表了真正的追求者“卓贾”。该类实现了 IGiveGift 接口，并包含了具体的送礼逻辑。

public class Pursuit implements IGiveGift {
    private SchoolGirl targetGirl;
    private final String pursuerName;

    public Pursuit(String name) {
        this.pursuerName = name;
    }

    public void setTargetGirl(SchoolGirl girl) {
        this.targetGirl = girl;
    }

    // 获取追求者姓名，用于代理类中的日志输出
    public String getName() {
        return this.pursuerName;
    }

    @Override
    public void giveDolls() {
        if (targetGirl != null) {
            System.out.println(this.targetGirl.getName() + ",你好！送你洋娃娃。");
        }
    }

    @Override
    public void giveFlowers() {
        if (targetGirl != null) {
            System.out.println(this.targetGirl.getName() + ",你好！送你鲜花。");
        }
    }

    @Override
    public void giveChocolate() {
        if (targetGirl != null) {
            System.out.println(this.targetGirl.getName() + ",你好！送你巧克力。");
        }
    }
}

在 Pursuit 类中，我们引入了 SchoolGirl 对象作为接收礼物的目标。每个送礼方法在执行时，都会检查目标对象是否存在，并输出相应的问候语。这里需要注意，Pursuit 类只关注送礼这一核心业务逻辑，不包含任何关于代理、计数或额外判断的逻辑，保持了类的纯净性和单一职责。

实现代理类

代理类 MyProxy 是本文的重点。它不仅实现了 IGiveGift 接口，还持有了 Pursuit 对象的引用。在每次调用送礼方法时，代理类会先执行前置逻辑（如打印代理行为），然后调用真实对象的方法，最后执行后置逻辑（如检查互动次数）。

public class MyProxy implements IGiveGift {
    private final String proxyName = "戴励";
    private Pursuit realPursuer;
    private SchoolGirl targetGirl;
    private int interactionCount = 0;

    public MyProxy(SchoolGirl girl) {
        // 在代理初始化时创建真实主题对象，体现代理对真实对象的生命周期管理
        this.realPursuer = new Pursuit("卓贾");
        this.targetGirl = girl;
        // 将目标对象注入到真实主题中
        realPursuer.setTargetGirl(girl);
    }

    @Override
    public void giveDolls() {
        // 前置处理：记录代理行为
        System.out.printf("%s帮%s执行操作:%n", proxyName, realPursuer.getName());
        // 调用真实主题的方法
        this.realPursuer.giveDolls();
        // 后置处理：检查业务状态
        checkInteractionStatus();
    }

    @Override
    public void giveFlowers() {
        System.out.printf("%s帮%s执行操作:%n", proxyName, realPursuer.getName());
        this.realPursuer.giveFlowers();
        checkInteractionStatus();
    }

    @Override
    public void giveChocolate() {
        System.out.printf("%s帮%s执行操作:%n", proxyName, realPursuer.getName());
        this.realPursuer.giveChocolate();
        checkInteractionStatus();
    }

    /**
     * 后置逻辑：模拟代理过程中的额外业务判断
     */
    private void checkInteractionStatus() {
        this.interactionCount++;
        // 当互动次数达到3次时，触发特定业务逻辑
        if (interactionCount >= 3) {
            System.out.printf("%s: 对不起好兄弟(%s),我爱上了她(%s)%n",
                    this.proxyName, this.realPursuer.getName(), this.targetGirl.getName());
        }
    }
}

在 MyProxy 的实现中，有几个关键点值得注意：

1. 生命周期管理：代理类在构造函数中创建了 Pursuit 实例，这意味着客户端不需要知道真实主题的存在，也不需要手动创建它。
2. 前置与后置增强：在每个送礼方法中，System.out.printf 语句作为前置逻辑，记录了代理人的行为；checkInteractionStatus 作为后置逻辑，实现了业务状态的监控。
3. 透明性：尽管内部逻辑复杂，但对于调用者来说，MyProxy 的行为与 Pursuit 完全一致，都遵循 IGiveGift 接口。

客户端测试代码

最后，我们通过一个简单的测试类来验证代理模式的工作流程。客户端只需要与 IGiveGift 接口交互，无需关心背后是代理还是真实对象。

public class ProxyPatternTest {
    public static void main(String[] args) {
        // 创建接收礼物的对象
        SchoolGirl girl = new SchoolGirl("李娇娇");

        // 创建代理对象，传入接收者
        // 注意：客户端只知道代理对象，不知道真实追求者的存在
        IGiveGift proxy = new MyProxy(girl);

        // 通过代理执行送礼行为
        proxy.giveDolls();
        proxy.giveFlowers();
        proxy.giveChocolate();
    }
}

在上述测试代码中，SchoolGirl 类是一个简单的数据载体，用于存储被追求者的姓名。运行这段代码，控制台将依次输出代理人的协助信息、真实追求者的送礼信息，以及在第三次互动后触发的特殊逻辑。这种设计使得业务逻辑的扩展变得非常灵活，如果需要修改送礼前的验证逻辑或送礼后的统计逻辑，只需修改 MyProxy 类，而无需触碰 Pursuit 核心业务代码。

深入解析 JDK 动态代理机制

在上述代码示例中，JDKProxyFactory 展示了如何利用 Java 反射机制在运行时动态生成代理对象。核心逻辑在于 Proxy.newProxyInstance 方法，它接收类加载器、接口数组以及一个 InvocationHandler 实例作为参数。类加载器用于定义生成的代理类，而接口数组则确保了代理对象能够实现与真实主题相同的契约。最关键的是 InvocationHandler，它充当了方法调用的拦截器，所有对代理对象方法的调用最终都会路由到其 invoke 方法中。这种设计使得我们可以在不修改原始业务代码的前提下，灵活地插入日志记录、权限校验或事务管理等横切关注点。通过这种方式，开发者可以将非业务逻辑从核心业务中剥离，极大地提升了代码的模块化程度和维护性。

public class JDKProxyFactory {
    public static IGiveGift createProxy(SchoolGirl mm, Pursuit gg) {
        return (IGiveGift) Proxy.newProxyInstance(
                gg.getClass().getClassLoader(), // 使用目标对象的类加载器
                gg.getClass().getInterfaces(),  // 获取目标对象实现的所有接口
                new InvocationHandler() {
                    private int count = 0;
                    private final String name = "戴励";

                    @Override
                    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                        count++;
                        // 前置增强：执行实际业务逻辑前的操作
                        System.out.printf("%s帮%s:%n", this.name, gg.getName());
                        // 通过反射调用目标对象的真实方法
                        Object result = method.invoke(gg, args);
                        // 后置增强：根据条件执行额外逻辑
                        if (count >= 3) {
                            System.out.printf("%s: 对不起好兄弟(%s),我爱上了她(%s)%n",
                                    this.name, gg.getName(), mm.name());
                        }
                        return result;
                    }
                });
    }
}

静态代理与动态代理的深度对比

为了更清晰地理解两种代理模式的差异，我们需要从代码维护性、扩展性以及底层实现原理三个维度进行剖析。静态代理虽然实现简单直观，每个代理类都明确指向特定的真实主题，但在面对大量需要代理的类时，会导致代码急剧膨胀，产生严重的冗余问题每增加一个业务接口，就必须手动创建对应的代理类，这违背了开闭原则。相比之下，JDK 动态代理通过反射机制在内存中动态构建代理类，无需为每个接口编写具体的代理实现，从而显著减少了样板代码。然而，动态代理并非没有代价，由于涉及反射调用和方法分派，其性能略低于静态代理，且在调试时由于缺乏具体的类文件，排查问题相对困难。此外，JDK 动态代理的一个显著限制是它只能代理实现了接口的类，如果目标对象没有实现任何接口，则无法使用此方案。

代理模式的核心应用场景

代理模式在实际软件开发中有着广泛且重要的应用，尤其适用于需要控制对象访问或增强对象功能的场景。首先是远程代理（Remote Proxy），它为位于不同地址空间（如远程服务器）的对象提供本地代表，隐藏了网络通信的复杂性，使客户端像调用本地对象一样调用远程服务，RMI 技术便是典型的应用案例。其次是虚拟代理（Virtual Proxy），常用于处理资源消耗较大的对象，例如图片加载或大文件读取，代理对象可以先显示占位符，直到真实对象完全加载后才进行替换，从而优化用户体验和系统启动速度。此外，保护代理（Protection Proxy）用于控制对原始对象的访问权限，根据不同用户的角色决定其是否有权执行特定操作，这在安全敏感系统中至关重要。最后，智能引用（Smart Reference）允许在访问对象时执行额外的辅助操作，如统计对象被引用的次数或在对象不再被引用时自动释放资源，这对于内存管理和性能监控极具价值。