设计模式 23 · 收尾总纲:把二十三式串成一张地图

到这里,「设计模式拆解」系列的正文就要收尾了。从第 1 篇的七大设计原则出发,我们一路走过了创建型 5 个、结构型 7 个、行为型 11 个,共二十三个 GoF 模式(其中冷门的三个合并在一篇讲)。这最后一篇不引入任何新模式,而是做四件事:把散落的模式盘进你天天用的源码里、集中辨析那几对最容易混的模式、再郑重地谈一次"过度设计"、最后把二十三式和七大原则收拢成一张完整的地图。读完这篇,前面二十二篇在你脑子里就不再是二十二个孤立的知识点,而是一个有主线、有脉络的整体。

目录

1. 源码里的模式:你早就在用它们
2. 最容易混的几对模式,集中辨析
3. 再谈过度设计:模式的正确打开方式
4. 一张全景地图:二十三式 × 七原则

一、源码里的模式:你早就在用它们

学模式最好的方式,是在你天天用的框架源码里认出它们。把前面各篇提到的现实身影汇总一下,你会发现:设计模式不是书本上的理论,而是所有优秀框架的通用语言。

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
• 观察者:ApplicationEvent+@EventListener事件机制
• 适配器:Spring MVC 的HandlerAdapter
• 责任链:HandlerInterceptor拦截器链
• 策略:Resource加载、各种可插拔策略
• 装饰器:BeanWrapper、各种Wrapper
• 外观:对复杂子系统的封装门面

MyBatis 里的模式:

• 建造者:SqlSessionFactoryBuilder
• 代理:Mapper 接口的动态代理(你只写接口没写实现,却能调用)
• 工厂:SqlSessionFactory

看到这个清单,你应该有两个体会:其一,你其实早就在用设计模式了,只是以前没意识到;其二,能读懂这些框架的设计,靠的正是对模式的理解——当你知道@Transactional底层是代理、JdbcTemplate是模板方法、@EventListener是观察者,框架对你就不再是黑魔法,而是一套你能看懂、能推理的设计。这就是学模式最实在的回报。

二、最容易混的几对模式,集中辨析

前面各篇里,我们一对对地辨析过那些"长得像"的模式。这里集中收拢,做一张"傻傻分不清"速查表——这几对是最高频的困惑点,一次记牢:

这张表里藏着一个深刻的规律:很多模式的类图几乎完全一样(代理/装饰器/适配器、策略/状态),区别根本不在结构,而在意图。这就是为什么"背 UML"学不好设计模式——因为光看结构,你分不清代理和装饰器。真正区分它们的,是"你想解决什么问题"。这也是本系列从头到尾强调"每个模式解决什么变化"、而不是"每个模式的类图长什么样"的原因。

三、再谈过度设计:模式的正确打开方式

从第 1 篇到现在,"别过度设计"这句话我在几乎每一篇都说了一遍。收尾了,必须把它作为最重要的一课郑重强调:学完二十三式,最大的风险不是"不会用",而是"到处用"。

一个刚学完设计模式的人,最典型的病症是:看什么代码都觉得"不够优雅",忍不住想套个模式;一个只有一种实现的接口非要配个工厂,一个永远两分支的判断非要拆成策略,一个三字段的对象非要上建造者……结果代码里全是接口、抽象类、各种 Xxx-Factory / Xxx-Strategy,跳转七八层才找到真正干活的那一行。这种"为了用模式而用模式"的代码,比不用任何模式的朴素代码更难维护。

请记住这几条,它们比二十三式本身更重要:

• 模式是用来解决"真实存在的变化"的,不是用来炫技的。先有值得解决的问题(这个维度真的在频繁扩展、这里真的有多种实现要切换),才谈得上用模式。没有问题硬套模式,就是过度设计。
• YAGNI(You Aren’t Gonna Need It):你不会需要它。别为"想象中未来可能有的扩展"提前铺一堆抽象。那个"未来"往往永远不来,而你为它付出的复杂度是当下就要承受的。
• 能用简单方案解决,就别上模式。一个if-else、一个直接new、一个普通方法,如果清晰够用,那它就是最好的设计。简单不是低级,清晰才是高级。
• 模式的引入应该是"重构出来的",而不是"设计出来的"。更健康的路径是:先写朴素的代码,当它真的开始因为某个变化而变得难受时(if-else 越来越长、复制粘贴越来越多),再用对应的模式去重构它。让模式在真实的痛点处自然长出来,而不是一开始就凭想象堆砌。

设计的最高境界,不是"用了多少模式",而是**“用最简单的结构,恰好解决了当前的问题,并为已经看清的变化留了余地”。二十三式给你的,是一套"当变化真的来临时,该怎么优雅应对"的标准答案库;但什么时候该翻开这个答案库、翻到哪一页,靠的是判断力**——而判断力的核心,就是分清"真实的变化"和"想象的变化"。

四、一张全景地图:二十三式 × 七原则

最后,把整个系列收拢成一张地图。二十三个模式按三大类归位,每个标出它主要贯彻的设计原则——你会看到,所有模式的底层,都是那七条原则(尤其是"组合优于继承"和"面向接口/依赖倒置")在不同场景下的具体落地。

从这张图里,能读出贯穿全系列的几条主线:

• "组合优于继承"是结构型的灵魂:代理、装饰器、适配器、桥接,几乎全在用"持有一个对象"代替"继承一个类"。这是本系列被验证次数最多的一条原则。
• "面向接口 + 依赖倒置"是几乎所有模式的地基:工厂、策略、观察者、状态、命令……无一不是"依赖一个抽象接口,而不是具体实现",再通过多态或注入切换具体实现。
• "隔离变化点"是所有模式的共同目的:每一个模式,本质上都是先识别出"这里有什么会变"(创建方式?算法?接口?状态?),然后给这个变化点一层抽象,把它和稳定的部分隔开。
• "开闭原则"是所有模式追求的效果:用了模式之后,面对变化时你几乎总能做到"新增代码而非修改代码"。

所以,如果要用一句话总结这整个系列,那就是:设计模式不是二十三个孤立的技巧,而是七大原则在"应对变化、降低耦合"这个共同目标下,结出的二十三颗果实。你真正要掌握的,不是二十三个模板,而是那套"识别变化 → 抽象隔离 → 面向接口 → 优先组合"的思维方式。模式会忘,思维方式不会。

全系列小结。「设计模式拆解」到此收官。我们从七大设计原则的地基出发,拆解了二十三个 GoF 模式:创建型解决"对象怎么被恰当地创建"(单例、工厂方法、抽象工厂、建造者、原型);结构型解决"类和对象怎么组合连接"(代理、装饰器、适配器、组合、外观、享元、桥接);行为型解决"对象之间怎么协作、职责怎么分配"(策略、模板方法、观察者、责任链、状态、命令、迭代器、中介者、备忘录、访问者、解释器)。全程用同一个订单场景贯穿,每个模式都落在"它消除了哪种耦合、应对了哪种变化"上,而不是停留在类图。

如果你只带走一句话,那应该是:模式是术,原则是道;识别真实的变化、用最简单的抽象去隔离它——这才是设计模式真正教给你的东西。剩下的,交给实战:在真实的痛点处,让合适的模式自然长出来。

感谢一路读到这里。愿你写出的代码,既能从容应对变化,又始终清爽、克制、恰到好处。