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的RestTemplateBuilder）
3. 结构型模式应用场景
3.1 适配器模式：解决接口不兼容问题
在系统迁移过程中经常遇到老接口适配问题。比如支付模块要接入新的第三方支付SDK：
public 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 List<OrderObserver> 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 Event
5. 模式混用与反模式识别
5.1 合理组合设计模式
在分布式锁实现中，我经常这样组合模式：
- 单例模式确保全局唯一锁管理器
- 模板方法定义加锁/解锁流程
- 策略模式支持不同锁实现（Redis/Zookeeper）
public 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
- 观察者模式：ApplicationEvent
7. 真实项目经验分享
在开发风控系统时，我们使用责任链模式处理规则校验：
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种模式，半年后回头看会有质的飞跃。