以下是一个使用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。