Java设计模式实战:电商与金融系统开发指南
1. Java设计模式实战指南设计模式是Java开发中绕不开的话题也是面试官最爱问的八股文之一。但很多人在学习时容易陷入两个极端要么死记硬背23种模式的UML图要么在项目中生搬硬套。我在电商和金融系统开发中踩过不少坑总结出一套理解本质-识别场景-合理选用的实践方法论。重要提示设计模式不是银弹过度使用反而会让代码变得难以维护。我见过最极端的案例是一个简单订单系统用了12种模式后来接手团队花了三个月重构。1.1 为什么需要设计模式想象你正在开发一个电商促销系统。最初版本可能只有满减优惠但随着业务发展很快会加入折扣券、积分抵扣、限时秒杀等复杂逻辑。如果一开始没有良好的设计代码会迅速腐化成面条式结构。这时设计模式就像乐高积木的连接件让各个模块既能灵活组合又保持清晰边界。Java标准库本身就是设计模式的教科书java.util.Collections#unmodifiableList()是装饰器模式java.util.Observable是观察者模式java.lang.Runtime#getRuntime()是单例模式2. 创建型模式实战精要2.1 工厂方法模式对象创建的封装艺术电商系统中商品分类是个典型案例。服装、数码、生鲜等商品虽然都继承自Product基类但创建逻辑差异很大public interface ProductFactory { Product createProduct(); } public class ElectronicsFactory implements ProductFactory { Override public Product createProduct() { // 包含保修期、规格参数等复杂初始化 return new ElectronicsProduct(); } }避坑指南避免创建过多工厂类可以用Map维护类型与工厂的映射关系考虑结合反射机制实现通用工厂但会损失编译期检查2.2 建造者模式分步构建复杂对象订单系统的Order对象包含数十个字段有些必填有些可选。传统构造器方式会导致参数爆炸Order order new Order.Builder() .userId(123) .addItem(item1) .shippingAddress(address) .applyCoupon(coupon) .build();实战技巧内部Builder类应该用static修饰对必填字段在build()方法中做校验适合配置类对象的构建如Spring的RestTemplateBuilder3. 结构型模式应用场景3.1 适配器模式解决接口不兼容问题在系统迁移过程中经常遇到老接口适配问题。比如支付模块要接入新的第三方支付SDKpublic class NewPaymentAdapter implements LegacyPaymentService { private final NewPaymentGateway gateway; public NewPaymentAdapter(NewPaymentGateway gateway) { this.gateway gateway; } Override public void pay(BigDecimal amount) { gateway.processPayment(amount.doubleValue()); // 类型转换 } }性能考量适配器会引入额外调用开销在高频调用场景要考虑缓存适配结果3.2 装饰器模式动态扩展功能IO流是经典案例我们在日志系统中也常用public class MetricsLogger implements Logger { private final Logger delegate; public MetricsLogger(Logger delegate) { this.delegate delegate; } Override public void log(String message) { long start System.nanoTime(); delegate.log(message); recordMetric(System.nanoTime() - start); } }设计原则符合开闭原则比继承更灵活。但要注意装饰顺序会影响最终行为4. 行为型模式最佳实践4.1 策略模式算法族的自由切换电商促销系统最适合用策略模式public interface DiscountStrategy { BigDecimal applyDiscount(Order order); } public class ChristmasDiscount implements DiscountStrategy { Override public BigDecimal applyDiscount(Order order) { return order.getTotal().multiply(0.8); } } // 使用上下文切换策略 public class PromotionContext { private DiscountStrategy strategy; public void setStrategy(DiscountStrategy strategy) { this.strategy strategy; } public BigDecimal executeStrategy(Order order) { return strategy.applyDiscount(order); } }性能优化如果策略无状态可以设计成单例复用4.2 观察者模式事件驱动架构基础订单状态变更通知是个典型场景public class Order { private ListOrderObserver observers new ArrayList(); public void addObserver(OrderObserver observer) { observers.add(observer); } private void notifyObservers(OrderEvent event) { observers.forEach(o - o.onEvent(event)); } public void cancel() { // 取消逻辑 notifyObservers(new OrderCancelledEvent(this)); } }注意事项小心观察者抛出异常导致通知中断考虑使用Guava的EventBus或Spring Event5. 模式混用与反模式识别5.1 合理组合设计模式在分布式锁实现中我经常这样组合模式单例模式确保全局唯一锁管理器模板方法定义加锁/解锁流程策略模式支持不同锁实现Redis/Zookeeperpublic abstract class DistributedLock { // 模板方法 public final boolean tryLock(long timeout) { if (acquireLock()) { try { return doLock(timeout); } finally { releaseLock(); } } return false; } protected abstract boolean doLock(long timeout); }5.2 常见反模式警示单例滥用导致测试困难考虑依赖注入过度装饰超过3层的装饰器会让调试变成噩梦策略爆炸当策略超过20个时应该考虑用规则引擎替代6. 面试高频问题剖析6.1 单例模式的线程安全实现面试官最爱问的问题之一。展示不同实现方式的演进// 1. 基础版非线程安全 public class Singleton { private static Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance null) { instance new Singleton(); } return instance; } } // 2. DCL双检锁注意volatile public class Singleton { private static volatile Singleton instance; public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } } // 3. 枚举实现最安全简洁 public enum Singleton { INSTANCE; public void businessMethod() {} }6.2 Spring中的设计模式面试加分项展示对框架的理解深度工厂模式BeanFactory代理模式AOP实现模板方法JdbcTemplate观察者模式ApplicationEvent7. 真实项目经验分享在开发风控系统时我们使用责任链模式处理规则校验public interface RiskHandler { void setNext(RiskHandler handler); boolean handle(Request request); } // 使用示例 RiskHandler chain new BlacklistHandler(); chain.setNext(new FrequencyHandler()) .setNext(new AmountLimitHandler()); if (!chain.handle(request)) { throw new RiskControlException(); }踩坑记录忘记调用nextHandler导致链条断裂没有控制链条长度导致栈溢出解决方案引入HandlerRegistry统一管理设计模式的学习应该像学成语一样先理解适用场景再通过刻意练习内化成编码直觉。我的建议是从你最熟悉的业务模块开始每次重点实践1-2种模式半年后回头看会有质的飞跃。