java设计模式：静态代理模式

以下是一个使用Java静态代理模式的示例，通过一个简单的银行转账场景来展示.

静态代理模式示例：银行转账系统

1. ​​定义抽象接口（Subject）​​

首先创建一个转账接口，声明核心方法：

public interface Transfer {
    void transfer(String fromAccount,
                  String toAccount,
                  double amount);
}

2. ​​实现真实主题类（RealSubject）​​

定义银行类作为核心业务类，实现转账逻辑：

public class Bank implements Transfer{
    @Override
    public void transfer(String fromAccount, String toAccount, double amount) {
        System.out.println(fromAccount + " 向 " + toAccount + " 转账 " + amount + " 元");
    }
}

3. ​​实现代理类（Proxy）​​

创建支付宝代理类，在核心转账操作前后添加额外功能：

public class Alipay implements Transfer{
    private Bank bank;

    public Alipay(){
        this.bank = new Bank();
    }

    // 代理类增强的方法
    private void identityVerification(String fromAccount, String toAccount, double amount){
        System.out.println("验证身份: " + fromAccount + " 和 " + toAccount);
        System.out.println("验证转账金额: " + amount);
    }


    private void afterService(){
        System.out.println("提供转账后续服务");
    }

    @Override
    public void transfer(String fromAccount, String toAccount, double amount){
        // 前置增强：身份验证
        identityVerification(fromAccount, toAccount, amount);
        // 调用核心业务逻辑
        bank.transfer(fromAccount, toAccount, amount);
        // 后置增强：服务支持
        afterService();
    }
}

4. ​​客户端测试​​

public class Test {
    public static void main(String[] args) {
        Alipay proxy = new Alipay();
        proxy.transfer("张三", "李四", 5000.0);
    }
}

5. 运行结果：

验证身份：张三 和 李四
验证金额：5000.0
张三 向 李四 转账 5000.0 元
提供转账后续服务

静态代理模式的优越性体现

1. 职责分离与代码解耦​​

• 代理类（Alipay）负责非核心业务（验证、服务），真实主题类（Bank）专注核心转账逻辑。
• 符合开闭原则​​：需新增功能（如日志记录）时只需修改代理类，无需改动核心代码。

​​2. 功能增强与访问控制​​

• 通过代理类无侵入式扩展功能（如身份验证），保护核心代码稳定性。
• 可控制访问权限​​：代理类可添加权限校验，禁止直接访问核心对象。

​​3. 安全性与灵活性​​

• 客户端通过代理间接访问核心对象，降低误操作风险​​。
• 易于扩展：若需支持微信代理，只需新建代理类实现相同接口，无需修改现有架构。

对比直接调用核心类的劣势

若直接使用YinHang类，验证和服务逻辑需写入核心方法，导致：

• 代码臃肿，核心业务与非核心逻辑耦合。
• 违反单一职责原则，增加维护成本。
• 无法灵活扩展新功能（如新增缓存代理需修改原类）。

总结

静态代理模式通过​​接口约束​​、​​代理类隔离 ​​和​​功能增强​​，实现了代码的可扩展性、安全性和可维护性。此案例展示了如何在不污染核心代码的前提下，系统性地增强业务逻辑，体现了代理模式在实际开发中的价值。

注意：静态代理需为每个真实类编写代理类，若接口频繁变更会增加维护成本。对于动态代理场景（如代理多个类），可考虑JDK动态代理或CGLIB。