1. 设计模式与设计原则软件工程的基石在软件工程领域设计模式和设计原则就像建筑师的蓝图和施工规范。它们不是具体的代码实现而是经过千锤百炼的最佳实践总结。我第一次真正理解设计模式的价值是在一个电商系统重构项目中——当时我们面对着一团乱麻般的订单处理逻辑各种if-else嵌套深达七八层。当我尝试用策略模式重构后代码量减少了40%而可维护性却提升了不止一个量级。设计模式通常分为三大类创建型处理对象创建、结构型处理对象组合、行为型处理对象交互。而设计原则则是这些模式背后的指导思想比如SOLID原则、DRY原则等。理解这些原则你就能在遇到新问题时自己发明出适合的模式而不仅仅是机械套用23种经典模式。2. 创建型模式灵活控制对象创建2.1 单例模式的正确实现方式单例可能是被滥用最多的模式。我曾见过用静态变量实现的伪单例在多线程环境下引发难以追踪的bug。正确的Java实现应该这样public class Singleton { private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance null) { synchronized (Singleton.class) { if (instance null) { instance new Singleton(); } } } return instance; } }注意点volatile关键字防止指令重排序双重检查锁定减少同步开销私有构造器阻止外部实例化实际项目中考虑使用枚举实现单例更简单安全Effective Java推荐方式2.2 工厂方法 vs 抽象工厂这两个模式经常被混淆。关键区别在于工厂方法创建单一产品如不同风格的按钮抽象工厂创建产品族如整套MacOS或Windows风格的UI控件在SaaS系统中我用抽象工厂实现多租户的UI主题切换interface ThemeFactory { Button createButton(); Dialog createDialog(); } class LightThemeFactory implements ThemeFactory { // 实现浅色系控件 } class DarkThemeFactory implements ThemeFactory { // 实现深色系控件 }3. 结构型模式构建灵活的对象结构3.1 适配器模式的实际应用最近在整合第三方支付接口时适配器模式派上了大用场。原有系统只支持支付宝现在要接入微信支付但两者接口差异很大// 原有支付宝接口 interface Alipay { void pay(BigDecimal amount); } // 微信支付SDK class WechatPay { public void sendPayment(double money) {...} } // 适配器 class WechatPayAdapter implements Alipay { private WechatPay wechatPay; public WechatPayAdapter(WechatPay wechatPay) { this.wechatPay wechatPay; } Override public void pay(BigDecimal amount) { wechatPay.sendPayment(amount.doubleValue()); } }3.2 组合模式的树形结构处理在处理组织架构、菜单系统等树形数据时组合模式能大大简化代码。关键点在于使叶子节点和复合节点实现同一接口interface Component { void render(); } class Leaf implements Component { public void render() { // 渲染叶子节点 } } class Composite implements Component { private ListComponent children new ArrayList(); public void add(Component c) { children.add(c); } public void render() { for (Component c : children) { c.render(); } } }4. 行为型模式优雅的对象交互4.1 观察者模式的现代实现传统的观察者模式在Java中可以用PropertyChangeSupport简化但更现代的写法是使用Java9的Flow APIclass NewsPublisher implements Flow.PublisherString { private final SubmissionPublisherString publisher new SubmissionPublisher(); public void subscribe(Flow.Subscriber? super String subscriber) { publisher.subscribe(subscriber); } public void publishNews(String news) { publisher.submit(news); } } class NewsSubscriber implements Flow.SubscriberString { private Flow.Subscription subscription; public void onSubscribe(Flow.Subscription subscription) { this.subscription subscription; subscription.request(1); } public void onNext(String item) { System.out.println(收到新闻: item); subscription.request(1); } // 其他方法省略... }4.2 策略模式与Lambda表达式在Java8中策略模式可以简化为函数式接口的使用interface DiscountStrategy { BigDecimal applyDiscount(BigDecimal amount); } class Order { private DiscountStrategy strategy; public void setStrategy(DiscountStrategy strategy) { this.strategy strategy; } public BigDecimal checkout(BigDecimal amount) { return strategy.applyDiscount(amount); } } // 使用 Order order new Order(); order.setStrategy(amt - amt.multiply(BigDecimal.valueOf(0.9))); // 九折策略5. SOLID原则深度解析5.1 单一职责原则(SRP)的误区很多人误以为一个类只做一件事就是指功能上的单一。实际上SRP更强调变更的原因要单一。例如用户类// 违反SRP的写法 class User { void saveToDatabase() {...} void sendEmail() {...} void validate() {...} } // 符合SRP的写法 class User { // 只包含核心属性和行为 } class UserRepository { void save(User user) {...} } class EmailService { void send(User user) {...} } class UserValidator { boolean validate(User user) {...} }5.2 里氏替换原则(LSP)的实际影响这个原则要求子类不能破坏父类的行为约定。我曾在项目中遇到过这样的问题class Rectangle { protected int width, height; void setWidth(int w) { width w; } void setHeight(int h) { height h; } int area() { return width * height; } } class Square extends Rectangle { Override void setWidth(int w) { super.setWidth(w); super.setHeight(w); } Override void setHeight(int h) { super.setWidth(h); super.setHeight(h); } }这段代码违反了LSP因为当Square被当作Rectangle使用时设置宽高的行为与预期不符。正确的做法是不要让Square继承Rectangle。6. 设计模式在面试中的应对策略6.1 高频面试题解析请手写线程安全的单例模式考察点多线程、延迟初始化、volatile关键字参考2.1节的实现谈谈你对Spring中IoC的理解关键点工厂模式的应用、控制反转与依赖注入可以结合模板方法模式分析Bean生命周期如何优化大量if-else的分支逻辑解决方案策略模式工厂模式示例interface Handler { boolean canHandle(Request req); Response handle(Request req); } class HandlerFactory { private ListHandler handlers; Response process(Request req) { return handlers.stream() .filter(h - h.canHandle(req)) .findFirst() .orElseThrow() .handle(req); } }6.2 设计模式在系统设计题中的应用当面试官要求设计一个电商系统时可以考虑以下模式订单状态流转状态模式支付方式扩展策略模式商品分类展示组合模式库存变更通知观察者模式优惠券系统装饰器模式7. 设计模式的误用与反模式7.1 过度设计的陷阱我曾参与重构一个滥用设计模式的代码库其中甚至为只有3个字段的DTO也加了抽象工厂。记住不要为了用模式而用模式KISS原则优先于设计模式模式应该随着需求演进自然出现而非预先设计7.2 常见反模式案例单例依赖地狱多个单例相互依赖解决方案改用依赖注入过度抽象为可能的需求提前抽象结果代码难以理解对策YAGNI原则(You Arent Gonna Need It)模式混用混乱如同时使用策略模式和状态模式处理同一问题区分策略是算法替换状态是行为随内部状态改变8. 现代开发中的模式演进8.1 函数式编程对模式的影响许多传统设计模式在函数式语言中变得简单甚至消失。例如策略模式 → 高阶函数观察者模式 → 事件流模板方法 → 函数组合Java中的示例// 传统策略模式 interface ValidationStrategy { boolean execute(String s); } // 函数式写法 PredicateString validationStrategy s - s.matches(\\d);8.2 响应式编程中的模式在Reactive系统中观察者模式演进为Publisher-Subscriber并加入了背压等新概念。Spring WebFlux就是典型应用。9. 个人实践心得模式学习路线建议先理解原则再学习模式从简单模式开始如策略、观察者通过重构现有代码应用模式调试技巧为模式添加有意义的日志使用IDE的UML工具可视化结构编写单元测试验证模式行为性能考量代理模式会增加调用开销享元模式能减少内存占用对象池模式适用于创建成本高的对象设计模式不是银弹但确实是每个高级开发者必须掌握的工具箱。我建议从实际项目中的痛点出发当发现代码难以扩展或维护时再寻找合适的设计模式来重构而不是一开始就试图用模式解决所有问题。