到这里,「设计模式拆解」系列的正文就要收尾了。从第 1 篇的七大设计原则出发,我们一路走过了创建型 5 个、结构型 7 个、行为型 11 个,共二十三个 GoF 模式(其中冷门的三个合并在一篇讲)。这最后一篇不引入任何新模式,而是做四件事:把散落的模式盘进你天天用的源码里、集中辨析那几对最容易混的模式、再郑重地谈一次过度设计、最后把二十三式和七大原则收拢成一张完整的地图。读完这篇,前面二十二篇在你脑子里就不再是二十二个孤立的知识点,而是一个有主线、有脉络的整体。目录源码里的模式:你早就在用它们最容易混的几对模式,集中辨析再谈过度设计:模式的正确打开方式一张全景地图:二十三式 × 七原则一、源码里的模式:你早就在用它们学模式最好的方式,是在你天天用的框架源码里认出它们。把前面各篇提到的现实身影汇总一下,你会发现:设计模式不是书本上的理论,而是所有优秀框架的通用语言。JDK 里的模式:单例:Runtime.getRuntime()工厂:Calendar.getInstance()、Collection.iterator()(工厂方法)、Connection(抽象工厂)建造者:StringBuilder、Stream.builder()原型:Object.clone()、ArrayList.clone()(浅拷贝)适配器:InputStreamReader(字节流转字符流)、Arrays.asList()装饰器:整个java.io(BufferedInputStream套FileInputStream)享元:Integer缓存(−128~127)、String常量池代理:java.lang.reflect.Proxy(动态代理)迭代器:Iterator/Iterable、for-each观察者:java.util.Observer(已废弃)模板方法:AbstractList、HttpServlet命令:Runnable责任链:ServletFilter策略:Comparator、ThreadPoolExecutor拒绝策略Spring 里的模式(几乎用全了):单例:Bean 默认作用域(容器级单例)工厂:BeanFactory、FactoryBean代理:AOP(JDK 动态代理 / CGLIB)——Transactional、Cacheable的底座模板方法:JdbcTemplate、RestTemplate、各种Template观察者:ApplicationEventEventListener事件机制适配器:Spring MVC 的HandlerAdapter责任链:HandlerInterceptor拦截器链策略:Resource加载、各种可插拔策略装饰器:BeanWrapper、各种Wrapper外观:对复杂子系统的封装门面MyBatis 里的模式:建造者:SqlSessionFactoryBuilder代理:Mapper 接口的动态代理(你只写接口没写实现,却能调用)工厂:SqlSessionFactory看到这个清单,你应该有两个体会:其一,你其实早就在用设计模式了,只是以前没意识到;其二,能读懂这些框架的设计,靠的正是对模式的理解——当你知道Transactional底层是代理、JdbcTemplate是模板方法、EventListener是观察者,框架对你就不再是黑魔法,而是一套你能看懂、能推理的设计。这就是学模式最实在的回报。二、最容易混的几对模式,集中辨析前面各篇里,我们一对对地辨析过那些长得像的模式。这里集中收拢,做一张傻傻分不清速查表——这几对是最高频的困惑点,一次记牢:易混的一对关键区别一句话记忆工厂 vs 建造者工厂管造哪个(选类型),建造者管怎么一步步造好一个(装配)工厂选择,建造者装配工厂方法 vs 抽象工厂工厂方法造一个产品,抽象工厂造一整族配套产品一个 vs 一族代理 vs 装饰器结构几乎一样,代理管控制访问,装饰器管增强功能代理把关,装饰加料装饰器 vs 适配器装饰器不改接口(增强),适配器改接口(转换)增强 vs 转换代理 vs 适配器 vs 装饰器看接口:代理/装饰器接口不变,适配器接口变只有适配器改接口策略 vs 状态结构几乎一样,策略是平行选一个算法,状态是按规则流转能画状态图的是状态策略 vs 模板方法策略用组合换整个算法,模板方法用继承换其中几步换整个 vs 换几步命令 vs 备忘录(撤销)命令记逆操作(增量),备忘录存快照(全量)反着做 vs 存整个外观 vs 中介者外观单向(简化外部调用),中介者双向(协调内部交互)单向门面 vs 双向协调桥接 vs 策略桥接分离两个长期演化的维度,策略替换一个算法分两轴 vs 换一算法这张表里藏着一个深刻的规律:很多模式的类图几乎完全一样(代理/装饰器/适配器、策略/状态),区别根本不在结构,而在意图。这就是为什么背 UML学不好设计模式——因为光看结构,你分不清代理和装饰器。真正区分它们的,是你想解决什么问题。这也是本系列从头到尾强调每个模式解决什么变化、而不是每个模式的类图长什么样的原因。三、再谈过度设计:模式的正确打开方式从第 1 篇到现在,别过度设计这句话我在几乎每一篇都说了一遍。收尾了,必须把它作为最重要的一课郑重强调:学完二十三式,最大的风险不是不会用,而是到处用。一个刚学完设计模式的人,最典型的病症是:看什么代码都觉得不够优雅,忍不住想套个模式;一个只有一种实现的接口非要配个工厂,一个永远两分支的判断非要拆成策略,一个三字段的对象非要上建造者……结果代码里全是接口、抽象类、各种 Xxx-Factory / Xxx-Strategy,跳转七八层才找到真正干活的那一行。这种为了用模式而用模式的代码,比不用任何模式的朴素代码更难维护。请记住这几条,它们比二十三式本身更重要:模式是用来解决真实存在的变化的,不是用来炫技的。先有值得解决的问题(这个维度真的在频繁扩展、这里真的有多种实现要切换),才谈得上用模式。没有问题硬套模式,就是过度设计。YAGNI(You Aren’t Gonna Need It):你不会需要它。别为想象中未来可能有的扩展提前铺一堆抽象。那个未来往往永远不来,而你为它付出的复杂度是当下就要承受的。能用简单方案解决,就别上模式。一个if-else、一个直接new、一个普通方法,如果清晰够用,那它就是最好的设计。简单不是低级,清晰才是高级。模式的引入应该是重构出来的,而不是设计出来的。更健康的路径是:先写朴素的代码,当它真的开始因为某个变化而变得难受时(if-else 越来越长、复制粘贴越来越多),再用对应的模式去重构它。让模式在真实的痛点处自然长出来,而不是一开始就凭想象堆砌。设计的最高境界,不是用了多少模式,而是**“用最简单的结构,恰好解决了当前的问题,并为已经看清的变化留了余地”。二十三式给你的,是一套当变化真的来临时,该怎么优雅应对的标准答案库;但什么时候该翻开这个答案库、翻到哪一页,靠的是判断力**——而判断力的核心,就是分清真实的变化和想象的变化。四、一张全景地图:二十三式 × 七原则最后,把整个系列收拢成一张地图。二十三个模式按三大类归位,每个标出它主要贯彻的设计原则——你会看到,所有模式的底层,都是那七条原则(尤其是组合优于继承和面向接口/依赖倒置)在不同场景下的具体落地。从这张图里,能读出贯穿全系列的几条主线:组合优于继承是结构型的灵魂:代理、装饰器、适配器、桥接,几乎全在用持有一个对象代替继承一个类。这是本系列被验证次数最多的一条原则。面向接口 依赖倒置是几乎所有模式的地基:工厂、策略、观察者、状态、命令……无一不是依赖一个抽象接口,而不是具体实现,再通过多态或注入切换具体实现。隔离变化点是所有模式的共同目的:每一个模式,本质上都是先识别出这里有什么会变(创建方式?算法?接口?状态?),然后给这个变化点一层抽象,把它和稳定的部分隔开。开闭原则是所有模式追求的效果:用了模式之后,面对变化时你几乎总能做到新增代码而非修改代码。所以,如果要用一句话总结这整个系列,那就是:设计模式不是二十三个孤立的技巧,而是七大原则在应对变化、降低耦合这个共同目标下,结出的二十三颗果实。你真正要掌握的,不是二十三个模板,而是那套识别变化 → 抽象隔离 → 面向接口 → 优先组合的思维方式。模式会忘,思维方式不会。全系列小结。「设计模式拆解」到此收官。我们从七大设计原则的地基出发,拆解了二十三个 GoF 模式:创建型解决对象怎么被恰当地创建(单例、工厂方法、抽象工厂、建造者、原型);结构型解决类和对象怎么组合连接(代理、装饰器、适配器、组合、外观、享元、桥接);行为型解决对象之间怎么协作、职责怎么分配(策略、模板方法、观察者、责任链、状态、命令、迭代器、中介者、备忘录、访问者、解释器)。全程用同一个订单场景贯穿,每个模式都落在它消除了哪种耦合、应对了哪种变化上,而不是停留在类图。如果你只带走一句话,那应该是:模式是术,原则是道;识别真实的变化、用最简单的抽象去隔离它——这才是设计模式真正教给你的东西。剩下的,交给实战:在真实的痛点处,让合适的模式自然长出来。感谢一路读到这里。愿你写出的代码,既能从容应对变化,又始终清爽、克制、恰到好处。