1. 从“看不懂”到“用得上”为什么HeadFirst设计模式能成为经典如果你在学设计模式大概率听过《Head First 设计模式》这本书。它和那些一上来就讲“单例模式确保一个类只有一个实例”的教科书完全不同。我第一次翻开它时感觉像在看一本漫画书满篇的对话、涂鸦和奇怪的比喻心里直犯嘀咕“这玩意儿能教会我写代码” 但恰恰是这种看似“不正经”的方式让我这个当初对着《设计模式可复用面向对象软件的基础》也就是那本著名的“GoF书”昏昏欲睡的新手第一次真正理解了策略模式、观察者模式这些概念到底在解决什么问题。这本书的核心价值不在于它罗列了多少种模式而在于它彻底颠覆了学习设计模式的路径。传统的学习路径是“定义 - 结构图 - 代码示例 - 适用场景”你记住了所有条条框框但面对一个具体的业务需求时大脑依然一片空白不知道哪个模式该上场。HeadFirst的路径则是“一个糟糕的设计 - 这个设计为什么让人头疼 - 如果我们这样改会不会好点 - 哦原来这就是XX模式”。它先让你“感同身受”坏代码的痛再带你一步步重构出好设计最后才告诉你这个好设计有个学名。这个过程就是把设计模式从一个需要死记硬背的“知识点”变成了一个可以随手拿来解决实际问题的“工具箱”。所以这篇内容不是对原书的简单复述或读书笔记。我想结合自己这些年从学习到应用再到在团队中推广设计模式思考的实战经历和你聊聊如何真正地“掌握”设计模式。我们会避开枯燥的理论堆砌聚焦于几个最核心、最常用也最容易产生误解的模式通过具体的场景拆解看看它们是如何在Java、C、Python乃至Spring框架中活起来的。无论你是正在为“设计模式大作业”发愁的学生还是想提升代码质量的职场开发者希望这些接地气的分析和“踩坑”心得能帮你跨过从“知道”到“会用”的那道鸿沟。2. 模式学习的最大误区把模式当目的而非解决方案我见过很多团队和个人的学习方式包括早期的我自己都陷入了一个经典的误区为了用模式而用模式。比如接到一个需求不是先去分析这个需求背后的核心复杂性和变化点而是先想“我这里能不能用个工厂模式那里是不是该用个装饰器” 这完全本末倒置了。设计模式是对特定场景下优秀解决方案的命名和总结它应该是你分析问题、得出方案后发现“咦我这个做法好像和某个模式描述的一样”时用来高效沟通的词汇而不是你设计开始的起点。这个误区在“设计模式大作业”中尤其明显。很多同学会做一个“动物园管理系统”或“图书管理系统”然后生硬地塞进去十几种模式每个类都继承自某个抽象类每个对象创建都要经过一个工厂代码结构复杂得像迷宫但功能却简单得用几十行过程式代码就能写完。老师一看用了很多模式给了高分但这样的代码在真实项目中是灾难——过度设计难以理解和维护。正确的打开方式应该是“问题驱动”。你需要培养的是识别“设计臭味”的能力。什么是设计臭味就是那些让你写代码、改代码时感到别扭、痛苦的地方。比如重复代码同一段逻辑散落在多个地方。庞大的类一个类做了太多事情职责不清。僵化的代码改一处功能却需要动许多看似不相关的地方。脆弱的代码看似简单的修改却导致程序莫名其妙地崩溃。当你闻到这些“臭味”时再去看设计模式手册你会发现每个模式都是在试图消除一种或多种特定的“臭味”。比如策略模式消除的是条件判断语句的重复和僵化观察者模式解决的是对象间紧耦合导致的脆弱性。先有问题和痛点再有模式和解决方案这个顺序绝不能错。3. 策略模式不是替换算法而是封装变化策略模式大概是HeadFirst书里讲得最透彻的一个模式因为它解决的场景太普遍了。书上用鸭子作为例子会飞、会叫的鸭子不同子类有不同行为。但很多人学完就只记得“把算法族封装起来让它们可以互相替换”然后就在自己的项目里到处找哪里可以“替换算法”。其实策略模式的精髓在于识别并封装“变化”。什么是变化就是那些在未来最有可能需要修改或扩展的部分。举个例子一个电商系统的折扣计算模块。初期可能只有“普通折扣”、“会员折扣”两种。新手可能会写一堆if-else或switch-casepublic double calculateDiscount(String userType, double price) { if (NORMAL.equals(userType)) { return price * 0.95; // 95折 } else if (VIP.equals(userType)) { return price * 0.85; // 85折 } else if (SVIP.equals(userType)) { return price * 0.75; // 75折 } // ... 更多折扣类型 return price; }这段代码的“臭味”是什么僵化且脆弱。每增加一种新的用户类型或折扣规则比如“满减”、“折扣券”你都必须来修改这个calculateDiscount方法的内部逻辑。这违反了“开闭原则”对扩展开放对修改关闭。用策略模式重构我们的思考过程是识别变化点变化的是“折扣计算算法”。封装变化点定义一个DiscountStrategy接口里面只有一个apply(double price)方法。创建具体策略为“普通折扣”、“会员折扣”、“满减策略”、“折扣券策略”分别实现这个接口。使用组合而非继承在订单或上下文类中持有一个DiscountStrategy的引用而不是硬编码计算逻辑。// 策略接口 public interface DiscountStrategy { double apply(double originalPrice); } // 具体策略 public class VipDiscount implements DiscountStrategy { Override public double apply(double originalPrice) { return originalPrice * 0.85; } } public class FullReductionDiscount implements DiscountStrategy { private double full; private double reduction; public FullReductionDiscount(double full, double reduction) { this.full full; this.reduction reduction; } Override public double apply(double originalPrice) { if (originalPrice full) { return originalPrice - reduction; } return originalPrice; } } // 上下文 public class Order { private DiscountStrategy discountStrategy; private double amount; public void setDiscountStrategy(DiscountStrategy strategy) { this.discountStrategy strategy; } public double getFinalAmount() { if (discountStrategy ! null) { return discountStrategy.apply(amount); } return amount; } }实战心得策略模式常与工厂模式结合使用谁来决定使用哪个具体策略通常不会由客户端直接new一个策略对象。我们可以用一个简单的“策略工厂”来根据类型字符串或枚举创建对应的策略对象。在Spring中这可以更进一步利用ApplicationContext根据Bean名称来获取策略Bean实现更灵活的管理。并非所有if-else都需要用策略模式重构如果策略类型非常固定比如就两三种且几乎不可能再扩展那么清晰的if-else可能比引入一堆类和接口更简单、更直接。过度设计也是成本。判断标准是“变化的可能性”和“修改的代价”。在C中的实现原理完全相同通过抽象基类定义接口具体策略类继承并实现。上下文类持有基类指针或引用。需要注意资源管理如使用std::unique_ptr。4. 观察者模式理解“推”与“拉”的权衡观察者模式定义了对象间的一种一对多依赖关系当一个对象主题状态改变时所有依赖它的对象观察者都会得到通知并自动更新。这个模式在GUI编程、事件驱动系统里无处不在。HeadFirst用气象站和多个布告板的例子非常生动。但实现观察者模式时有一个关键的设计决策常常被忽略主题在通知观察者时应该传递什么数据这衍生出两种模型“推”模型和“拉”模型。“推”模型主题在调用观察者的更新方法时直接将变更的数据作为参数传递过去。比如update(temperature, humidity, pressure)。优点是观察者直接拿到所需数据方便。缺点是主题必须“知道”所有观察者需要什么数据接口可能会变得臃肿。如果以后有新的观察者需要新的数据就必须修改主题的notifyObservers方法和所有观察者的接口违反了开闭原则。“拉”模型主题在通知时只传递一个自身的引用或一个获取数据的上下文。观察者收到通知后自己调用主题的方法来“拉取”感兴趣的数据。比如update(WeatherStation station)然后在方法内部station.getTemperature()。优点是主题和观察者接口稳定主题不需要关心观察者要什么。缺点是观察者需要知道如何从主题获取数据增加了观察者和主题的耦合尽管是松耦合的。Java内置的支持java.util.Observable类和java.util.Observer接口提供了一套观察者模式的实现。但需要注意的是Observable是一个类而不是接口这限制了它的使用Java不支持多重继承。在现代Java开发中更推荐自己定义接口或者使用PropertyChangeSupport等工具类或者直接使用响应式编程库如RxJava、Project Reactor它们提供了更强大、更类型安全的观察者模式变体。在Spring框架中的应用Spring的事件机制是观察者模式的经典实现。ApplicationEvent代表事件主题的状态变化ApplicationListener代表观察者。ApplicationContext就是那个主题ApplicationEventPublisher。当你发布一个事件context.publishEvent(new MyEvent(this, data))所有监听该事件的Listener都会收到通知。这是典型的“推”模型事件对象本身承载了数据。Spring内部大量使用这种机制比如ContextRefreshedEvent容器刷新完成、RequestHandledEvent请求处理完毕等让你能在生命周期的特定节点插入自定义逻辑。C实现的注意事项在C中实现观察者模式要特别注意对象生命周期管理。如果主题持有观察者的裸指针而观察者先于主题被销毁主题再去通知就会访问野指针导致崩溃。常见的解决方案有使用智能指针如std::shared_ptr和std::weak_ptr。主题持有std::weak_ptrObserver通知前尝试提升为shared_ptr提升失败则说明观察者已失效将其从列表中移除。让观察者在析构时主动向主题注销自己。这要求观察者持有主题的引用实现起来稍显繁琐。使用信号槽库如Qt中的信号槽机制。Qt的信号槽是类型安全且自动管理连接的在断开连接或对象销毁时更安全是观察者模式在C GUI领域的一个优秀实践。《Qt C设计模式实战指南》中肯定会重点讲解这一部分。5. 装饰器模式给爱丽丝穿衣服还是组装流水线HeadFirst用给咖啡加调料摩卡、奶泡的例子来讲装饰器模式非常形象。装饰器模式动态地给一个对象添加一些额外的职责就增加功能来说比生成子类更为灵活。它通过组合和委托实现了功能的“嵌套”。但很多人看完例子容易产生一个误解装饰器就是简单地“包装”一层。其实它的核心价值在于保持接口一致性前提下的功能扩展。装饰器和被装饰的对象实现同一个接口因此对客户端来说使用一个被装饰过的对象和使用原始对象没有任何区别。这使得你可以透明地、递归地组合多个装饰器。一个更贴近开发的例子是Java I/O库。FileInputStream是一个被装饰的组件BufferedInputStream和DataInputStream就是装饰器。你可以这样组合InputStream in new DataInputStream(new BufferedInputStream(new FileInputStream(test.txt)));BufferedInputStream装饰了FileInputStream为其添加了缓冲功能DataInputStream又装饰了BufferedInputStream为其添加了读取基本数据类型的功能。每一层装饰都保持了InputStream的接口。与继承的对比如果用继承来实现上述功能你需要创建BufferedFileInputStream、DataFileInputStream、BufferedDataFileInputStream等一系列类。类的数量会爆炸式增长组合爆炸。而装饰器模式通过组合用少量的装饰器类就可以实现无数种功能组合。在Python中的灵活应用Python凭借其函数作为一等公民和装饰器语法的特性让装饰器模式变得极其自然和强大。Python的装饰器decorator本身就是一种实现装饰器模式的语法糖但它通常用于装饰函数或方法。对于装饰对象我们依然可以使用传统的类装饰器模式但更多时候Python开发者会利用其动态特性通过猴子补丁或__getattr__等方法来实现类似功能代码更简洁。实战中的坑装饰顺序可能影响结果比如一个加密装饰器和一个压缩装饰器先加密再压缩和先压缩再加密结果是完全不同的。设计时需要明确装饰器的顺序是否重要。大量小对象过度使用装饰器会产生大量细粒度的对象可能对性能尤其是内存和初始化时间有轻微影响。在性能极度敏感的场景需要权衡。初始化复杂客户端代码在构造最终对象时可能需要嵌套多层new代码可读性会变差。这时可以考虑结合工厂模式或建造者模式来简化对象的创建过程。6. 工厂模式简单工厂、工厂方法、抽象工厂别再傻傻分不清工厂模式大概是命名最混乱、最让人困惑的一组模式了。GoF书里定义了“工厂方法”和“抽象工厂”但实践中还有一个被广泛使用的“简单工厂”它甚至不算一个正式的设计模式。我们来彻底理清它们。6.1 简单工厂一个方法决定一切简单工厂就是一个类里面有一个静态方法或非静态根据传入的参数返回不同类的实例。它封装了对象创建的细节。public class PizzaFactory { public static Pizza createPizza(String type) { Pizza pizza null; if (cheese.equals(type)) { pizza new CheesePizza(); } else if (pepperoni.equals(type)) { pizza new PepperoniPizza(); } else if (clam.equals(type)) { pizza new ClamPizza(); } // 可能进行一些统一的初始化操作 pizza.prepare(); pizza.bake(); return pizza; } }它的缺点违反了开闭原则。每增加一种新的Pizza类型都必须修改createPizza方法中的if-else逻辑。但当产品类型相对固定且变化不频繁时简单工厂因其简单直观而被大量使用。6.2 工厂方法将实例化推迟到子类工厂方法模式定义了一个创建对象的接口但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。HeadFirst的例子是PizzaStore。有一个抽象的PizzaStore它有一个createPizza(String type)的抽象方法。NYPizzaStore和ChicagoPizzaStore继承它并实现各自的createPizza方法分别创建纽约风味和芝加哥风味的披萨。public abstract class PizzaStore { public Pizza orderPizza(String type) { Pizza pizza createPizza(type); // 这就是工厂方法 pizza.prepare(); pizza.bake(); pizza.cut(); pizza.box(); return pizza; } // 工厂方法由子类实现 protected abstract Pizza createPizza(String type); } public class NYPizzaStore extends PizzaStore { Override protected Pizza createPizza(String type) { if (cheese.equals(type)) { return new NYStyleCheesePizza(); // 纽约风味的芝士披萨 } // ... 其他纽约风味披萨 return null; } }核心优势符合开闭原则。要增加一个新的地区风味如加州风味只需要新建一个CaliforniaPizzaStore类并实现createPizza即可原有的PizzaStore和其他地区的Store都不需要修改。它将“产品”和“创建者”之间的绑定解耦了。6.3 抽象工厂创建产品家族抽象工厂模式提供一个接口用于创建相关或依赖对象的家族而不需要明确指定具体类。简单说工厂方法创建“一种”产品而抽象工厂创建“一族”产品。假设我们的披萨店不仅要生产披萨还要生产配套的餐具餐盒、刀叉。纽约店和芝加哥店用的餐具风格也不同。// 抽象工厂接口 public interface KitchenFactory { Pizza createPizza(String type); Tableware createTableware(); } // 具体纽约工厂 public class NYKitchenFactory implements KitchenFactory { Override public Pizza createPizza(String type) { // 返回纽约风味的披萨 return new NYStyleCheesePizza(); } Override public Tableware createTableware() { // 返回纽约风格的餐具可能是环保纸盒 return new NYStyleTableware(); } } // 具体芝加哥工厂 public class ChicagoKitchenFactory implements KitchenFactory { Override public Pizza createPizza(String type) { // 返回芝加哥风味的披萨 return new ChicagoStyleCheesePizza(); } Override public Tableware createTableware() { // 返回芝加哥风格的餐具可能是硬质塑料盒 return new ChicagoStyleTableware(); } }这样客户端只需要依赖KitchenFactory接口就可以获得一整套风格一致的产品披萨和餐具而无需关心具体的实现类。Spring框架的BeanFactory就是一个巨大的、超级抽象的工厂它负责创建和管理应用中的所有Bean产品并且可以通过不同的配置如XML、Java Config、注解来生产不同“风格”即不同实现的Bean。如何选择简单工厂对象创建逻辑简单且产品类型有限、不常变化。快速实现避免代码分散。工厂方法无法预知需要创建哪种具体产品或者希望将产品创建延迟到子类以便于扩展新的产品类型。抽象工厂需要创建一系列相互关联或依赖的产品对象并且希望保证这些产品之间的兼容性。它强调的是“产品族”。7. 单例模式最简单的模式最深的坑单例模式恐怕是面试中被问得最多也是在实际项目中被误用、滥用最多的模式。它的意图很简单确保一个类只有一个实例并提供一个全局访问点。但实现一个正确、高效、线程安全的单例尤其在多线程环境下并不简单。7.1 懒汉式线程不安全public class Singleton { private static Singleton instance; private Singleton() {} // 私有构造器 public static Singleton getInstance() { if (instance null) { instance new Singleton(); // 多线程下可能创建多个实例 } return instance; } }这是最基础的版本但在多线程环境下是致命的。如果两个线程同时检查到instance null它们会各自创建一个实例。7.2 懒汉式同步方法public static synchronized Singleton getInstance() { if (instance null) { instance new Singleton(); } return instance; }通过给方法加synchronized锁解决了线程安全问题但每次获取实例都要同步性能有损耗。7.3 双重检查锁定DCLpublic class Singleton { private volatile static Singleton instance; // 注意 volatile 关键字 private Singleton() {} public static Singleton getInstance() { if (instance null) { // 第一次检查 synchronized (Singleton.class) { if (instance null) { // 第二次检查 instance new Singleton(); } } } return instance; } }这是经典的、高效的线程安全懒汉式实现。volatile关键字在这里至关重要它防止了指令重排序确保了instance被完全初始化后才被其他线程看到。在Java 5及以后版本中volatile的语义得到增强此写法才安全。7.4 静态内部类Holder方式public class Singleton { private Singleton() {} private static class SingletonHolder { private static final Singleton INSTANCE new Singleton(); } public static Singleton getInstance() { return SingletonHolder.INSTANCE; } }这是我最推荐的一种实现。它利用了Java类加载机制静态内部类SingletonHolder只有在被引用时才会加载而类加载过程是线程安全的。这样既实现了懒加载又无需同步代码还简洁。7.5 枚举方式public enum Singleton { INSTANCE; public void doSomething() { // ... } }这是《Effective Java》作者Joshua Bloch大力推荐的方式。枚举实例的创建是线程安全的且能防止反射攻击和序列化/反序列化破坏单例。简洁、安全、功能强大。单例模式的“坑”与反思全局状态的弊端单例本质上是一个全局变量。它使得代码的耦合度变高难以测试因为无法轻易替换模拟对象也违背了“依赖注入”的原则。在现代Spring应用中我们通常将Bean的作用域声明为singleton但那是容器管理的单例而不是自己用代码实现的静态单例。Spring的单例更易于测试和替换。破坏单例除了多线程反射和序列化也可以破坏普通的单例。枚举单例能天然防御这两种攻击。使用场景单例适合用于那些真正意义上“全局唯一”的资源比如线程池、缓存、日志管理器、配置对象等。不要仅仅为了“方便访问”就把一个工具类做成单例。很多时候通过依赖注入将实例传递进去是更好的选择。8. 模式之外的思考如何将模式融入日常开发学完一堆模式最后还是要落到怎么写代码上。我的体会是不要总想着“我这个模块该用哪个模式”而应该培养以下习惯8.1 优先使用组合而非继承这是大多数设计模式的基础如策略、装饰器、观察者。组合提供了更大的灵活性可以在运行时改变行为并且让类的层次结构保持扁平。继承应主要用于表示“是一个is-a”的关系并且要警惕深层次的继承树。8.2 针对接口编程而不是针对实现编程这是HeadFirst反复强调的原则。声明变量、方法参数、返回类型时尽量使用接口或抽象类。这降低了代码的耦合度使得替换具体实现变得非常容易。List list new ArrayList();而不是ArrayList list new ArrayList();。8.3 拥抱重构小步快跑不要指望在项目一开始就设计出完美的、包含所有模式的架构。优秀的架构是随着对需求的理解加深而逐渐演进而来的。当你发现代码有“臭味”时重复、庞大、僵化、脆弱就是重构的信号。此时设计模式就是你重构工具箱里的扳手和螺丝刀。例如看到一大片条件判断可以考虑是否能用策略模式或状态模式来消除看到两个类关系过于亲密可以考虑引入中介者模式或观察者模式来解耦。8.4 理解原则模式是手段设计模式背后是更底层的设计原则最著名的就是SOLID原则单一职责原则一个类只做一件事。开闭原则对扩展开放对修改关闭。里氏替换原则子类必须能够替换其父类。接口隔离原则客户端不应依赖它不需要的接口。依赖倒置原则依赖抽象而非具体。模式是这些原则在特定场景下的具体体现。理解了原则你甚至可以在不记得模式名称的情况下自然地写出符合模式思想的代码。当你的代码符合这些原则时它自然会具备良好的可读性、可维护性和可扩展性。最后回到HeadFirst的精神上来学习设计模式最好的方法不是背诵而是动手。找一个你以前写过的、感觉有点“乱”的小项目用今天聊到的思路去重新审视它看看哪些地方可以引入策略模式来消除条件判断哪些模块可以用观察者模式来解耦。在不断的“识别臭味 - 思考模式 - 重构代码”的循环中这些模式才会真正内化成你的设计本能。记住没有银弹复杂的模式用在简单的需求上就是过度设计而恰当的模式用在复杂的变化点上就是化腐朽为神奇。
)
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
