以下是一个使用Java静态代理模式的示例，通过一个简单的银行转账场景来展示.
静态代理模式示例：银行转账系统
1. 定义抽象接口（Subject）
首先创建一个转账接口，声明核心方法：
java
public interface Transfer {
void transfer(String fromAccount,
String toAccount,
double amount);
}2. 实现真实主题类（RealSubject）
定义银行类作为核心业务类，实现转账逻辑：
java
public class Bank implements Transfer{
@Override
public void transfer(String fromAccount, String toAccount, double amount) {
System.out.println(fromAccount + " 向 " + toAccount + " 转账 " + amount + " 元");
}
}3. 实现代理类（Proxy）
创建支付宝代理类，在核心转账操作前后添加额外功能：
java
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. 客户端测试
java
public class Test {
public static void main(String[] args) {
Alipay proxy = new Alipay();
proxy.transfer("张三", "李四", 5000.0);
}
}5. 运行结果：
java
验证身份：张三 和 李四
验证金额：5000.0
张三 向 李四 转账 5000.0 元
提供转账后续服务静态代理模式的优越性体现
1. 职责分离与代码解耦
- 代理类（Alipay）负责非核心业务（验证、服务），真实主题类（Bank）专注核心转账逻辑。
- 符合开闭原则：需新增功能（如日志记录）时只需修改代理类，无需改动核心代码。
2. 功能增强与访问控制
- 通过代理类无侵入式扩展功能（如身份验证），保护核心代码稳定性。
- 可控制访问权限：代理类可添加权限校验，禁止直接访问核心对象。
3. 安全性与灵活性
- 客户端通过代理间接访问核心对象，降低误操作风险。
- 易于扩展：若需支持微信代理，只需新建代理类实现相同接口，无需修改现有架构。
对比直接调用核心类的劣势
若直接使用YinHang类，验证和服务逻辑需写入核心方法，导致：
- 代码臃肿，核心业务与非核心逻辑耦合。
- 违反单一职责原则，增加维护成本。
- 无法灵活扩展新功能（如新增缓存代理需修改原类）。
总结
静态代理模式通过接口约束、代理类隔离 和功能增强，实现了代码的可扩展性、安全性和可维护性。此案例展示了如何在不污染核心代码的前提下，系统性地增强业务逻辑，体现了代理模式在实际开发中的价值。
注意：静态代理需为每个真实类编写代理类，若接口频繁变更会增加维护成本。对于动态代理场景（如代理多个类），可考虑JDK动态代理或CGLIB。