从背名词到真正会用：设计模式学习路线与Java/C++实战复盘

「设计模式」这三个字可能是我见过被误解最深的计算机术语。大三那年我第一次翻开GoF那本经典书读到抽象工厂那一章就彻底崩溃——满眼都是看不懂的类名和关系图完全想不明白学了能干嘛。后来经历了期末突击、大作业赶工、真实项目重构踩了无数坑才慢慢明白23种设计模式根本不是让你背的目录而是前人把代码写成屎山之后总结出来的“后悔药”。这篇内容就是把我从“背名词”到“真正会用”的完整过程复盘一遍包括期末和大作业到底怎么准备、Java与C实现的真实差异以及那个被低估最严重的原型模式。希望对正在为设计模式头秃的人有点用。1. 设计模式为什么难学先搞清楚它到底是个什么东西1.1 模式不是规则是踩坑后的“后悔药”很多初学者最大的误区是把设计模式当成“必须遵守的规范”来学觉得代码里不套几个模式就很不专业。实际上设计模式的定义里最关键的一个词是“反复出现的问题”。它本质上是一份经验总结某个场景下前人用某种结构解决了问题踩过的坑、趟过的雷都写在里面后来者直接复用这个方案就不用再死一遍。我用一个生活化的例子说明。你第一次做红烧肉按照菜谱一步步来发现提前焯水比直接下锅好吃第二次做发现小火炖比大火收汁肉质更嫩第三次做发现加一点冰糖能提色。把这些经验写成文字就是“红烧肉模式”。设计模式同理——它是“代码界的菜谱”记录的是“当你的对象创建逻辑开始失控时试试这样处理”“当你的算法需要随意切换时试试这样组织”。所以学习设计模式的正确心态不是“我要在代码里用满23种模式”而是“当我遇到某种坏味道时我知道有一个成熟套路可以抄”。带着问题去学比带着目录去背效率高十倍。1.2 学之前必须过关的三块地基不少同学一上来就啃模式结果连代码都看不懂问题多半出在地基没打好。我总结了三个前置知识点不过关的话后面全是空中楼阁第一接口与抽象类的区别。Java里interface和abstract class怎么选C里纯虚函数和虚函数意味着什么这是理解大部分模式的前提。比如策略模式的核心就是“面向接口编程”你连接口都理解不透策略模式就只能是背公式。第二多态。设计模式里的很多“魔法”本质都是多态在起作用父类引用指向子类对象调用同一个方法却表现出不同行为。工厂模式返回的是接口类型实际装的是具体实现模板方法模式在父类里定骨架子类重写钩子方法——这些都是多态的典型应用。第三“组合优于继承”这条设计原则。初学者写代码特别喜欢extends到底觉得继承又省事又符合直觉。但继承的耦合度太高父类一改子类全崩。GoF在书里反复强调优先使用组合而不是继承很多模式装饰器、策略、状态都是在用组合解决继承解决不了的问题。这三块地基如果你已经会了可以直接往下看如果还模糊建议花两个晚上把它们彻底搞清楚否则后面所有模式都学不踏实。1.3 最容易踩的三种学习姿势错误我见过太多人学设计模式翻车姿势惊人地一致第一种按目录从头到尾啃。从单例开始然后工厂方法、抽象工厂、建造者、原型……像背单词一样一个个过。结果就是“学完就忘忘了再看看了再用不出来”。因为目录顺序是作者按分类排的不是你按认知规律排的。第二种只看UML类图不看代码。类图当然重要但光看类图会产生一种“我懂了”的错觉。实际上类图画起来都很像一个接口、几个实现类、几条箭线。真正能区分模式好坏的是代码里的细节——为什么这里用接口而不是抽象类为什么这个引用要传进来而不是内部new这些只有写代码才能体会。第三种只背名字不背“问题”。考试的时候题目问“什么时候用观察者模式”你能答出“一对多依赖状态变化通知所有依赖者”就算过关了但工作中遇到“订单状态变了要同步刷新好几个页面”的场景你根本想不起来这就是观察者模式。模式的名字不重要它对应的问题场景才重要。2. 别按目录背把23种模式按“要解决的问题”重新分组GoF把23种模式分成创建型、结构型、行为型三大类。这个分类本身没问题问题是很多初学者把这个分类当成“背诵大纲”背完就完。我的建议是分类记在心里但学的时候一定要围绕“它解决什么问题”来展开。2.1 创建型5种搞定“对象怎么来”创建型模式解决的核心问题是当对象创建逻辑变得复杂时把“创建”这件事封装起来让使用方不依赖具体类。单例模式解决“全局只需要一个实例”的问题比如配置管理器、线程池工厂方法把“创建哪种对象”的决策延迟到子类抽象工厂解决“一系列相关对象需要配套创建”的问题比如UI组件库里的按钮和输入框必须风格统一建造者模式解决“对象构造参数太多、步骤太复杂”的问题典型场景就是组装一台电脑CPU、内存、硬盘一堆参数原型模式解决“创建对象成本太高不如直接复制一个”的问题。学创建型有个小技巧想一想如果没有这个模式代码会变成什么样。没有工厂你到处new具体类换个实现要改一堆地方没有单例你满世界传同一个配置对象。模式的价值一下就出来了。2.2 结构型7种搞定“对象怎么组装”结构型模式关注的是类与对象之间的组合关系目标是让结构更灵活、复用性更高。适配器模式解决“接口不兼容”的问题就像你有一个Type-C口的手机需要一个转接头插旧耳机装饰器模式解决“动态给对象加功能”的问题奶茶加珍珠加椰果就是典型的装饰器每一层包装都保持“奶茶”这个抽象身份代理模式解决“不想直接访问原对象”的问题比如给房子找中介外观模式解决“子系统太复杂提供一个简单门面”的问题就像前台帮你对接整个公司的各种部门桥接模式解决“多个维度独立变化”的问题比如形状和颜色两个维度各成一套组合模式解决“部分和整体需要一致对待”的问题文件夹和文件都能被双击打开享元模式解决“大量细粒度对象重复创建、内存爆炸”的问题比如文本编辑器里成千上万个字符对象共享样式。结构型模式学起来最容易混淆因为它们都涉及“包一层”。我的判断方法很简单加了一层但是为了兼容适配器、为了增强装饰器、为了控制访问代理、为了简化入口外观四者目的完全不同考试时抓住“目的”就不会错。2.3 行为型11种搞定“对象怎么协作”行为型模式数量最多也最容易让人崩溃。我的经验是先抓最常用的几个再逐个击破。最常用的是策略模式和观察者模式。策略模式把一组可互换的算法封装起来比如支付方式的选择观察者模式解决“一对多通知”的问题比如公众号发布文章自动推送给所有订阅者。接下来是模板方法模式把算法骨架定在父类里具体步骤交给子类命令模式把“请求”封装成对象实现撤销重做状态模式把“状态相关的行为”拆分到不同状态类里比如一个订单系统里待支付、已支付、已发货三种状态的处理逻辑完全不一样责任链模式让多个处理者依次尝试处理同一个请求审批流程就是典型场景。剩下几个——解释器、中介者、备忘录、迭代器、访问者——说实话工作中用得相对少尤其是解释器和访问者日常业务代码里很少碰。考试可能会考概念但不需要投入太多精力。2.4 一张速查表看到什么需求找哪一组我整理了一张自己的速查表期末复习和大作业选型的时候特别好用遇到什么问题先去哪一组找典型模式对象创建太乱、不想直接new创建型工厂、单例、建造者、原型类和类之间结构需要解耦结构型适配器、装饰器、代理、外观算法需要动态切换行为型策略、模板方法一个变化要通知多个对象行为型观察者请求需要排队、撤销、重做行为型命令对象太多、内存吃紧结构型享元状态不同、行为完全不同行为型状态这张表不需要背它的作用是帮你建立“问题到模式”的映射直觉。用多了你就会发现设计模式学的根本不是代码是“识别问题”的能力。3. 期末怎么考、大作业怎么拿分从学生视角拆评分标准3.1 期末考试的四类典型题目设计模式期末的题型其实非常固定我结合自己考过的和帮学弟学妹辅导时见过的基本逃不出四类。第一类是概念题直接问“什么是单例模式”“列举三种创建型模式”。这种题最没技术含量但最容易丢分因为很多人背了个大概就上考场写出来的定义没有踩到关键词。比如单例模式的定义必须包含“一个类只有一个实例”和“提供一个全局访问点”这两个要点少一个就扣分。第二类是场景识别题给你一段需求描述问“最适合用哪种模式”。这是最经典的考题也最考验“问题到模式”的映射能力。比如题干说“多种算法可以互相替换运行时动态选择”那答案基本就是策略模式“一个对象状态变化其他对象跟着更新”那就是观察者模式。这类题目的答题套路是先提炼题干里的核心动词和关系——替换、通知、兼容、包装、创建再看对应哪类模式。第三类是UML类图补全题给出一个模式的应用场景让你画出类图结构。这种题只要记住每个模式的经典类图结构就能拿分核心是接口/抽象类在顶部具体实现在底部关联关系用箭头正确表达。我见过很多人把依赖关系和关联关系画反白白丢分。第四类是代码填空题或改错题。给出一段残缺的代码让你补全某一句或者指出代码中不符合某个模式的地方。这种题最实在练过一遍比背十遍都管用。3.2 场景识别题的核心记住每个模式的“一句话特征”我学设计模式时做了一件事帮助特别大把每种模式压缩成一句话而且必须能脱离代码、用生活语言说清楚。单例全局只要一个谁拿都是同一个。工厂我不知道具体要哪个让工厂告诉我。建造者参数太多太复杂一步一步来。原型创建太贵了给我复制一份。适配器接口不匹配加个转接头。装饰器不能改原类一层层加功能。代理不方便直接访问找个替身。外观一堆子系统太乱给我一个简单入口。策略算法一换行为就变。观察者你变了我就知道。模板方法骨架定好步骤我定。状态状态不同做的事情不同。命令把请求打包想撤销就撤销。考试前把这些句子背熟遇到场景题先对号入座准确率能提高一大截。因为这正是出题老师的出题逻辑他们用一段具体场景描述某个模式的本质特征只要你抓住了特征就能识别出来。3.3 大作业选题与模式搭配我建议的三种系统设计模式大作业最常见的坑是选题太复杂或者太简单。太复杂的结果是写到一半写不完代码全糊成一团太简单的结果是套不上几个模式凑不够工作量。我推荐三类系统难度适中模式嵌入非常自然第一点餐/购物系统。单例管购物车或店铺配置工厂方法按菜品类型创建订单策略模式处理不同支付方式或优惠计算装饰器可以给汉堡/饮品加料观察者模式让订单状态变化通知用户。整套下来轻松用上5个模式而且逻辑通顺。第二图书管理系统。单例管图书馆实例建造者构造不同规格的书籍对象模板方法定义借书、还书的流程骨架状态模式处理图书在馆、借出、预约三种状态命令模式实现借还操作的撤销。这个选题的好处是领域简单老师一眼能看懂。第三宿舍报修或教室预约系统。外观模式封装报修流程的多个环节观察者模式通知维修师傅和同学策略模式处理不同故障类型的处理优先级责任链模式让报修请求依次经过宿管、维修组、后勤处。选择系统时我的核心建议是先画出这个系统的“自然状态流转”再看哪些环节天然适合用模式而不是先定模式再强行凑场景。强行凑出来的代码一眼假老师扣分毫不留情。3.4 大作业最容易丢分的三个地方第一只有代码没有图。很多人的大作业就是堆了一堆代码文件既没有类图也没有模式说明。老师没耐心去你的代码里考古你至少要在文档里为每个模式配一张类图写清楚“为什么用这个模式、不用会怎样”。这套“场景-问题-方案”的论证逻辑比代码本身更值钱。第二模式之间没有关联。有些作业像拼盘五个模式各管各的互相之间毫无关系。其实好的大作业应该是“一条主链路串联多个模式”。比如点餐系统里工厂创建订单→装饰器添加配料→策略计算价格→观察者通知后厨→单例管理全局配置。模式之间有调用关系整个系统才像一个整体。第三多个单例到处飞。有些同学为了让模式数量好看把缓存、日志、配置、数据库连接全部写成单例结果就是全局状态泛滥代码之间隐性耦合严重。单例模式的核心价值在于“确实只有一个实例且必须全局共享”如果只是为了省事那宁可不用。4. Java实现设计模式的四个高频细节从能跑提升到跑对4.1 单例模式五种写法与volatile的来历单例模式是考试出现频率最高的模式Java里至少有五种写法饿汉式、懒汉式、双检锁DCL、静态内部类、枚举。几乎每个版本的期末卷子都会考到它们的区别。饿汉式最简单类加载时就创建实例public class ConfigManager { private static final ConfigManager INSTANCE new ConfigManager(); private ConfigManager() {} public static ConfigManager getInstance() { return INSTANCE; } }缺点是没有延迟加载如果这个类一直没被用到实例就白创建了。懒汉式能延迟加载但最简单的写法有线程安全问题多个线程同时进入getInstance可能创建多个实例。双检锁DCL是经典考题public class ConfigManager { private static volatile ConfigManager instance; private ConfigManager() {} public static ConfigManager getInstance() { if (instance null) { synchronized (ConfigManager.class) { if (instance null) { instance new ConfigManager(); } } } return instance; } }这里volatile是必考点。为什么非要加因为instance new ConfigManager()这行代码在JVM层面不是原子的它分三步分配内存、初始化对象、把引用指向内存。如果不加volatile编译器可能把“把引用指向内存”重排到“初始化对象”之前另一个线程就会拿到一个未初始化完成的对象。这个问题面试也爱问答上来能加不少印象分。最推荐的写法其实是静态内部类利用类加载机制的线程安全性既实现了延迟加载又没有同步开销。枚举写法更是被《Effective Java》称为“最完美的单例”因为枚举天然防止反射和序列化破坏单例。但考试时老师多半让你写双检锁因为这个最能考出你对并发和JMM的理解。4.2 策略模式的现代写法从接口传参到Lambda一行教科书里的策略模式是定义策略接口写多个实现类然后通过构造函数或setter把策略对象注入。这种写法完全没毛病但如果你的作业代码里全是只写一个方法的小类会显得很啰嗦。Java 8之后函数式接口让策略模式的实现变得非常轻量。比如定价策略传统写法要写三个类public interface Pricer { double price(double original); }然后写StudentPricer、VipPricer、NormalPricer三个实现类。但用Lambda在调用处直接写Order order new Order(100); order.setPricer(price - price * 0.8); // 学生价 order.setPricer(price - price * 0.95); // VIP价“策略”从一个个具体类变成了一个行为参数。这也是为什么现在很多讲设计模式的书会专门补一章“Lambda与模式”策略、模板方法、命令这些模式在函数式接口的加持下都有了更现代的写法。大作业里用这种写法代码量能少一半而且更能体现你对Java语言本身的理解。但要注意函数式写法只适合“策略本身只是一个函数”的场景。如果策略之间共享大量内部状态或者需要维护复杂属性还是老老实实写类更清晰。4.3 工厂与泛型别为了“通用”把代码写复杂Java实现工厂模式时很多初学者喜欢上泛型恨不得写一个“万能工厂”public class FactoryT { public T create(Class? extends T clazz) throws Exception { return clazz.getDeclaredConstructor().newInstance(); } }这种写法看起来很高端实际上典型过度设计。泛型反射工厂的问题在于你在运行期用反射绕过了编译期类型检查一旦类没有无参构造方法就会在运行时抛异常。我的建议是工厂模式的价值在于“集中管理创建逻辑”把new的细节收拢到一个地方而不是“消灭所有硬编码”。所以别怕在工厂里写switch或if-else这正是工厂该干的事情。真正的进阶方向不是泛型魔法而是让工厂返回接口类型、让调用方只依赖接口。你把客户端代码里的具体类引用全部改成接口引用就达到了工厂模式的90%目的。4.4 观察者模式JDK自带类被废弃后的替代方案老教材讲到观察者模式一定会提java.util.Observer和java.util.Observable。但这两个类在Java 9之后被标记为废弃了原因是Observable不是一个接口而是类限制了子类的独立性而且事件模型不够灵活。所以我建议大作业里不要用这两个类否则老师会觉得你还在用十年前的知识。替代方案有三个自己定义观察者接口最推荐也最符合学习模式的目的用PropertyChangeListener配合PropertyChangeSupport或者用Spring的ApplicationEvent机制——但大作业一般没必要引入框架依赖。自己写一个观察者模式并不难public interface OrderListener { void onOrderChanged(Order order); } public class Order { private final ListOrderListener listeners new ArrayList(); public void addListener(OrderListener listener) { listeners.add(listener); } public void notifyChanged() { for (OrderListener listener : listeners) { listener.onOrderChanged(this); } } }这段代码虽然简陋但把“订阅”“发布”的关系表达得非常清楚。大作业用这个老师反而更喜欢因为能看到你对机制本身的理解而不是只会调库。5. 用C写设计模式和Java完全不同的四个坑如果你选了C方向——不少学校设计模式课是C和Java两开花的——那你要比Java同学多操心很多事情。C没有GC没有interface关键字内存管理全靠自觉设计模式写起来完全是另一种画风。我帮人改了不少C版模式大作业最常见的坑就下面四个。5.1 虚析构函数不是可选项工厂模式返回基类指针这是C版大作业的标准操作class Product { public: virtual ~Product() default; }; class ConcreteProductA : public Product { /* ... */ }; Product* p factory.create(A); delete p;如果Product的析构函数不是虚函数那么delete p只调用Product::~Product()而ConcreteProductA的析构函数不会被调用它的成员资源就泄漏了。这个错误非常隐蔽程序不崩溃但内存稳步上涨老师审查代码时一眼就能看出来。规则很简单只要基类可能被多态删除基类析构函数就必须是虚的。在老代码里写virtual ~Product() {}在新标准里写virtual ~Product() default;效果一样。5.2 单例的局部静态变量线程安全但析构顺序成迷C11以后局部静态变量的初始化是线程安全的所以最简单的单例写法是ConfigManager getConfigManager() { static ConfigManager instance; return instance; }这个写法秒杀Java的双检锁既延迟加载又线程安全是C里最推荐的单例实现。但它有个隐藏问题析构顺序不确定。如果另一个单例A的析构函数里用到了ConfigManager而程序结束时ConfigManager先被析构了A再去访问就会触发未定义行为。这就是传说中的“单例析构地狱”。大作业场景下一般碰不到这个问题但考卷上可能会问。我的建议是能不用单例就不用单例C里单例的正确打开方式是“万不得已然后析构函数里别碰其他单例”。5.3 观察者模式的悬垂指针内存管理的真实考验Java写观察者模式完全不用考虑观察者的生命周期——GC会帮你收拾。C里如果观察者先于被观察者析构而被观察者的事件列表里还存着观察者的裸指针那么事件一触发就是访问已释放内存的经典悬垂指针问题。解法有两种思路。第一种是观察者在析构时主动调用removeListener把“退订”做成强制动作这对代码规范要求很高。第二种是用std::weak_ptr保存观察者触发事件时先lock()如果观察者已死就跳过。第二种更安全但写起来啰嗦一些。我见过太多C大作业在这里翻车程序跑着跑着随机崩溃改了半天找不到原因其实就是某个窗口对象关了之后没有退订。所以用C写观察者模式一定要在文档里写明“生命周期管理方案”这反而能成为加分点——说明你意识到C和Java在内存模型上的本质差异。5.4 原型模式的深拷贝C默认拷贝构造会坑你C实现原型模式靠拷贝构造函数和虚函数class Enemy { public: virtual ~Enemy() default; virtual std::unique_ptrEnemy clone() const 0; }; class Goblin : public Enemy { std::vectorstd::string skills; public: std::unique_ptrEnemy clone() const override { return std::make_uniqueGoblin(*this); } };这段代码正确的前提是Goblin的拷贝构造函数把skills正确地深拷贝了。如果skills是裸指针默认拷贝构造只是复制指针地址结果就是两个对象共享同一份数据改一个另一个也变——这就是浅拷贝陷阱。在这点上C比Java更危险因为Java的引用语义是语言内置的而C的值语义太容易让人误以为拷贝已经是深拷贝了。6. 原型模式深挖最被低估、也最常被讲错的模式6.1 原型模式到底在解决什么问题23种模式里原型模式是最被低估的一个。它经常被一句话带过——“通过复制现有对象来创建新对象”很多人听完就完了完全感受不到它的价值。原型模式解决的真正问题是“当对象创建的成本很高或者对象类型在运行期才能确定”的时候。所谓创建成本高可能是指构建这个对象要查数据库、发网络请求、做大量计算——比如一个加载了全套技能数据和模型资源的游戏角色。你需要在游戏里生成100个同类型怪物如果每次都从头加载资源性能灾难但如果第一个怪物创建好之后后面的就复制它成本直线下降。另一个场景是运行期类型不确定。你的代码里拿到一个抽象的Shape想再创建一个和它一样的新对象但运行时无法知道它的具体类型。这时如果Shape接口提供了clone()你就能“我不用知道你是圆还是方复制一个就完事”。这种“让对象自己产出自己的副本”的思路正是原型模式的核心。6.2 深拷贝浅拷贝考试和大作业最爱的考点原型模式考试题里出现频率最高的就是“深拷贝和浅拷贝的区别”。这个概念其实不难但很多人理解得模模糊糊。浅拷贝就是只复制最外层对象对象里的引用类型字段直接拷贝引用地址新旧对象共享同一个内部对象。深拷贝则是把所有层级的对象全部复制一遍新旧对象互不影响。用现实类比浅拷贝等于你把自己家的钥匙复制了一份给别人别人开门进屋你家的东西就动了深拷贝是把你的房子重新盖了一模一样的别人进去折腾的是他的房子跟你无关。Java里Object.clone()默认就是浅拷贝。要做深拷贝得手动处理每个可变引用字段。C里默认拷贝构造函数同理。区分深浅的关键是看对象里有没有引用类型或指针类型的可变成员。期末如果考这个一般会给你一个类让你判断哪个成员需要深拷贝、怎么写练几道题就有手感了。6.3 为什么都说Java的Cloneable反人类Java的Cloneable接口被很多人诟病是“设计失误”。原因有三。第一它是个标记接口里面没有声明任何方法。真正要覆盖的是Object类里的protected clone()这意味着你的对象要复制自己得先把可见性改成public还得强转类型Override public Enemy clone() { try { return (Enemy) super.clone(); } catch (CloneNotSupportedException e) { throw new RuntimeException(e); } }第二super.clone()是浅拷贝如果成员里有final修饰的可变对象引用clone出来还是指向同一个对象想要深拷贝还得手工重建。第三它绕过了构造函数这让对象创建流程有违直觉也容易破坏不可变类的约束。所以我的实际建议是学习原型模式可以用Cloneable来理解概念但在大作业里与其强行实现Cloneable不如自己写一个copy()或clone()方法用构造方法或工厂创建副本思路更清晰也更容易控制深拷贝逻辑。老师不会因为你用了原生Cloneable加分但会因为你把深拷贝写得明明白白而给好评。6.4 原型模式的真实应用场景从游戏到配置系统原型模式在真实项目里的出场率比你想象的高。最常见的场景就是游戏开发怪物、技能、道具都是典型的“原型克隆”模式。我认识一个做游戏的朋友说过他们生成小怪就是先做一个模板实例然后clone()一堆出来再在上面随机调参——性能好代码也简洁。另一个典型场景是文档和表格应用。你在图形编辑器里画了一个矩形复制粘贴出一个一模一样的矩形再把位置拖一下——这背后就是原型模式。图形对象创建成本不高但它的状态颜色、大小、样式已经配好了复制比你从头new一个再调低效率高得多。再一个是配置系统。系统默认配置是一个原型对象每个新用户或者新租户创建时先拷贝默认配置原型再修改自己的差异化部分。如果每次都从零构建一份全量配置代码会变得臃肿且容易漏字段。这些场景的共同点是无论是性能需要创建昂贵还是类型需要运行时才知道类型原型模式都能提供比“直接new”更合理的答案。7. 我的学习路线与最后几点实操心得7.1 期末速成两周复习计划如果你离考试还有两周别想着把23种模式全部学透那不现实。我的速成路线是第一周只学六个高频模式单例、工厂方法、抽象工厂、策略、观察者、模板方法。这六个占了考题的六成以上。每个模式的学法是固定的三步看概念定义、画UML类图、写一个最简Java实现。写完再看装饰器、适配器、状态、命令这四个次高频模式同样三步走。第二周开始刷题。找往年卷子或者课后题重点刷场景识别题和代码填空题。刷的时候要求自己“说出理由”为什么是这个模式如果换成另一个模式为什么不行。此外把每个模式的“一句话特征”整理到一张A4纸上每天睡前默背一遍。两个提醒第一别背各模式的代码细节背特征和类图结构考场上你能画出来、能讲清楚为什么分数就到手了第二大作业如果和期末撞在一起优先保大作业——因为大作业能系统地展示你对多个模式的理解期末是碎片化考察前者的容错空间更大。7.2 长期路线从“会画类图”到“会重构”如果时间充裕我真心建议别为考试学设计模式。真正让设计模式内化的方式是重构。找一段自己以前写的烂代码——功能能跑但改起来想哭的那种——然后问自己我为什么觉得它烂大概率是因为某个地方变化点太多或者类之间耦合太紧。这时候再翻设计模式的书找到对应章节哦这里用策略模式可以消除switch这里用工厂可以收拢new这里用观察者可以解耦。带着问题去用模式用完之后再看代码你会产生一种“通了”的爽感这是背目录永远给不了的。另一个好方法是在开源项目里做“模式考古”。读JDK源码时你会发现Collections.synchronizedList()是装饰器模式Runtime.getRuntime()是单例模式Iterator是迭代器模式。在别人的优秀代码里认出模式比在自己的代码里强行安插模式收获大得多。7.3 踩过这些坑之后的个人体会最后分享一点我自己的体会。学设计模式最忌讳的是把它当成一个“完成了就不看了”的知识点。我的实际经验是模式是练出来的不是背出来的。我自己真正能熟练脱口而出的模式也就那十来个剩下那些我记住了名字和大概用途真到场景里我再翻书查证也不迟——这完全不丢人因为设计模式本来就是一个既有知识的“工具箱”随时查、随时用才是它该有的形态。还有个私藏小技巧当你觉得自己写代码越来越“绕”的时候往往意味着模式选错了。好的模式应用应当是让代码结构更简单、更直白——如果再读一遍代码觉得抽象层太多、跳来跳去看不懂那就是过度设计。模式是服务代码的不是代码伺候模式的。这句话是我在无数次把简单代码改成“满屏模式”然后又改回来之后最想说给你听的。