如果你打开搜索引擎搜“设计模式”被 23 个模式的类图和各种语言的实现刷屏第一反应是关掉页面这太正常了。我在团队里带过不同基础的同事也在面试里看过太多“背得熟”却“用不出”的候选人。设计模式的问题从来不是难学而是学习顺序错了它不是一本需要背诵的类图字典而是一类反复出现的问题的成熟解法。这篇我会用一个老程序员的工作视角把模式的底层逻辑、三类 23 个模式的主线、Java/C/C# 里的落地差异以及软考、期末、大作业、面试的答题框架一次讲清楚尽量让零基础的人也知道从哪下手、怎么用起来。1. 先别急着背 23 个模式搞清楚它们到底在解决什么问题1.1 模式是路标不是菜谱很多人一上来就搜“设计模式简介”然后被“类、对象、耦合、复用”这些词劝退。我特别理解。我自己刚学的时候也对着 GOF 那本《设计模式》头晕满脑子都是“我怎么可能背下来 23 个”。后来工作久了才发现设计模式根本不是用来背的而是用来“认”的。Erich Gamma 等四人总结的 23 个模式本质上是把软件工程几十年里反复出现的设计问题以及被验证过的解决骨架归纳成了几组。它们就像路标看到“适配器”你该想到两边接口对不上看到“代理”你该想到访问控制、延迟加载或者日志看到“观察者”你该想到一个状态变了一群人要响应。没有这些路标你也能靠硬编码把功能写出来但代码会越来越拧巴改一个需求牵一发动全身。你可以把设计模式理解成装修工程的“标准工序”。每套房子户型不同但水电怎么走、防水怎么做、瓷砖怎么铺都有成熟的套路。你不需要每次从零发明一套而是先判断我的情况属于哪种典型场景再套用对应的成熟做法。设计模式的价值就在这里把重复踩坑的经验沉淀成可复用的结构。1.2 零基础的正确学习姿势场景、冲突、方案我见过不少同学直接去背“工厂模式有几个角色、类图怎么画”背完就忘。因为那是从结论出发没有经历问题本身。更好的学习顺序是场景 → 冲突 → 方案。举个最常见的例子。你要写一个支付模块一开始只支持微信支付代码很简单一个类搞定。三个月后要加支付宝你可能会写 if/else。再加银联、银行卡这个 if/else 会越来越长每次新增渠道都要改老代码测试也越来越痛苦。这时候你发现的问题就是工厂模式和策略模式要解决的问题。你带着这个痛点去学一学就会而且永远不会忘。所以我的建议是三步走复现每个模式用最小代码写一遍不追求背类图而是体会模式的骨架。辨识在别人的代码里找模式。Spring、JDK、.NET、C 标准库里到处都是模式认出来比写出来更重要。改造在真实需求里刻意用一次。哪怕一开始有点过度设计也没关系关键是体会“如果没有这个模式改动会发生在哪里”。很多人“背了 23 个期末考完就忘”就是因为只做到第一步。设计模式是技能不是知识点。技能需要肌肉记忆需要在真实的代码里反复触发。2. 真正的地基SOLID 原则才是你选模式的尺子2.1 五个原则的大白话版本在开始分门别类讲模式之前我强烈建议你先理解 SOLID 原则。因为模式是“术”原则是“道”。经常有新手问我这个场景该用工厂还是策略其实答案藏在原则里你到底要隔离哪种变化单一职责原则SRP一个类最好只有一个引起它变化的原因。不要把订单计算、日志、持久化全部塞进一个 OrderService后面改任何一块都会误伤另外两块。开闭原则OCP对扩展开放对修改关闭。加新功能时尽量不修改已经写好并且测试过的旧代码。比如加优惠策略时不去改原来的打折方法而是新增一个策略类。里氏替换原则LSP凡是用父类的地方换成子类不能出问题。经典的“正方形继承长方形”反例就是宽高单独设置时正方形的行为会破坏父类约束。接口隔离原则ISP客户端不应该依赖它用不到的接口。与其放一个大而全的接口不如拆成几个小接口。依赖倒置原则DIP面向抽象编程不面向具体实现编程。业务代码依赖 PayChannel 接口而不是依赖 WeChatPay 实现类。这五个原则不是考试背诵题而是代码评审时的判断依据。你在 code review 里说“这个类太长了”“这个接口太胖了”“这里不该 new 具体的实现”本质上都是在用 SOLID 说话。2.2 原则是怎么导向模式的原则本身不会直接告诉你用哪个模式但它们会指出变化点。我自己的判断习惯是先问“这段代码将来最可能因为什么而变”再顺着变化点找模式。举个例子如果变化点在“对象的创建方式”比如类型经常增加、构造参数很复杂优先考虑工厂方法、抽象工厂、建造者。如果变化点在“行为算法”比如折扣、运费、税率规则经常调整优先考虑策略模式。如果变化点在“通知关系”比如订单状态一变短信、邮件、积分都要跟着动优先考虑观察者。如果变化点在“接口形态”比如要兼容老系统、第三方 SDK 的接口优先考虑适配器。如果变化点在“访问控制”比如某些接口只允许特定角色调用优先考虑代理。你可以用下面这张表快速定位原则它真正在问什么常见关联模式单一职责这个类会不会因为多个原因被修改状态、策略、观察者开闭原则加功能时旧代码动不动工厂、策略、装饰器、观察者里氏替换子类能不能无缝替换父类模板方法、策略接口隔离接口是不是最小可用适配器、外观依赖倒置业务是否依赖抽象抽象工厂、工厂方法、依赖注入每次纠结“该用哪个模式”的时候不要盯着模式列表看回到问题本身最需要被隔离的变化点是什么。想清楚这一句模式自然浮出来。3. 创建型模式把“对象怎么来的”从业务逻辑里拆出去3.1 单例模式最容易背最容易用错单例是面试里非常爱考的小题因为它看起来简单坑却非常多。它的目标是保证一个类只有一个实例并提供全局访问点。常见场景是配置中心、连接池、日志对象。Java 里一个线程安全的懒汉单例要写成这样public class Config { private static volatile Config instance; private Config() {} public static Config getInstance() { if (instance null) { synchronized (Config.class) { if (instance null) { instance new Config(); } } } return instance; } }volatile不能省否则在并发下可能拿到半初始化对象。C 从 C11 开始最简单的方式是“局部静态变量”class Logger { public: static Logger getInstance() { static Logger instance; return instance; } Logger(const Logger) delete; Logger operator(const Logger) delete; private: Logger() default; };C# 直接用LazyT最省心。面试时你能说出这三种语言的差异基本上单例这块就过关了。但我要提醒你一句单例是全局可变状态的温床。多人协作时大家都会往单例里塞数据测试用例之间互相污染排查问题非常痛苦。能用依赖注入把实例传进去就别直接去拿单例。3.2 工厂方法家族从“简单工厂”到“抽象工厂”简单工厂其实不属于 GOF 的 23 个模式但它是最常见的第一步用一个方法集中创建对象。public class PayFactory { public PayChannel create(String type) { if (alipay.equals(type)) { return new AlipayChannel(); } if (wechat.equals(type)) { return new WechatChannel(); } throw new IllegalArgumentException(unknown pay type); } }这段代码的优点是调用方不用关心具体类缺点是每次加渠道都要改这个 if/switch违反开闭原则。想彻底解决就升级成工厂方法模式把create做成抽象方法每种渠道一个子工厂新增渠道时新增一个子工厂不动旧代码。抽象工厂再进一步它负责创建“一族”相关的对象。比如一个 UI 主题按钮、输入框、弹窗必须是配套风格。你要深色主题就有一个 DarkThemeFactory 同时产出深色按钮和深色弹窗要浅色主题就有 LightThemeFactory。关键词是“产品族”。面试时经常被问“工厂和抽象工厂有什么区别”一句话回答工厂方法解决“一个产品”的创建抽象工厂解决“一族产品”的配套创建。3.3 建造者与原型复杂对象的两种快捷方式建造者模式适合构造参数特别多、并且希望对象创建后不可变的场景。比如组装一台电脑直接 new 一个几十个参数的构造函数谁看谁崩溃。用 Builder 链式调用Computer c new Computer.Builder() .cpu(i7-13700K) .gpu(RTX 4070) .ram(32G) .disk(2T SSD) .build();建造者和工厂的区别是工厂关心“造出什么类型”建造者关心“一步步把复杂对象拼好”。很多框架里的Builder就是这种模式比如 Lombok 的Builder、OkHttp 的Request.Builder。原型模式适合创建成本高的对象。你有一份默认的商品模板每次新商品都复制一份再改少量字段而不是从零建。注意浅拷贝和深拷贝Java 的clone()默认是浅拷贝C 要自己写拷贝构造否则两个对象会共享内部数组改一个等于改了全部。我在项目中一般优先推荐使用拷贝工厂或序列化复制少依赖语言原生 clone逻辑更透明。创建型模式的口诀可以是单工建原抽。对应单例、工厂方法、抽象工厂、建造者、原型五个一起记期末考试分类题基本不会丢分。4. 结构型模式类和对象的组装方式决定你改代码是轻松还是难受4.1 适配器、装饰器、代理三个长得像职责完全不一样结构型模式里最容易被混淆的三个是适配器、装饰器、代理因为它们都是“在一个类外面再包一层”。但包的目的完全不同。适配器解决接口不匹配。现实类比是电源转换头三脚插头转两脚。代码里典型例子是InputStreamReader它把一个字节流InputStream适配成字符流Reader两边不用改。装饰器解决能力增强。它给对象动态叠加功能不改原类。Java IO 是最好例子new BufferedInputStream(new FileInputStream(...))BufferedInputStream给原始文件流加了缓冲能力。你还可以继续包DataInputStream加读取基本类型的能力。代理解决访问控制。代理类和目标类实现同一个接口外面看起来一样但真正干活前可以加权限校验、延迟加载、日志记录。Spring AOP 的动态代理就是典型。一句话区分接口对不上用适配器功能要叠加用装饰器对象不能直接碰用代理。面试时用这三句话开头再补个例子基本就稳了。4.2 外观、组合、桥接、享元这四个在结构型里也很有用。外观模式是给复杂子系统开一个简洁的门面。比如你写一个OrderFacade把库存扣减、支付、物流三个服务串起来调用方只需要调placeOrder()不需要知道内部有五个类在协作。它降低的是使用方的认知成本。组合模式解决树形结构。文件夹里有文件和子文件夹但客户端可以统一调用getName()不用区分当前是文件还是文件夹。菜单、目录树、组织架构图都可以用它。关键是让单个对象和组合对象实现同一个接口。桥接模式解决“两个维度独立变化”的问题。比如图形有圆形、方形绘制引擎有 OpenGL、DirectX。如果你用继承每加一个图形就要多好几个子类。桥接的做法是图形类里组合一个绘制引擎接口画图时委托给引擎。抽象与实现各自扩展互不干扰。享元模式是批量共享不可变状态省内存。Java 的Integer缓存 -128 到 127、String 常量池都是享元思想。用共享时要注意把“内蕴状态”和“外蕴状态”分开内蕴状态可以共享外蕴状态由外部传入。结构型的共同点是尽量用对象组合代替继承。组合比继承更灵活代价是代码变绕、间接层变多。所以结构型模式不是用得越多越好而是发现类出现爆炸式增长时才需要。5. 行为型模式把“动作和交互”变成可插拔的策略5.1 策略、状态、模板方法处理行为变化的三个主力策略模式解决“算法替换”。比如优惠计算满减、折扣、赠品每次新增规则不去改主业务类的 if/else而是新增一个策略类。调用方只面向一个DiscountStrategy接口运行时切换具体实现。用 Java 写可以简化成public interface DiscountStrategy { double apply(double amount); }C 里甚至不需要定义接口直接用一个std::functiondouble(double)就能当策略std::functiondouble(double) discount [](double price) { return price * 0.8; };状态模式和策略模式长得有点像但意图不同。策略是客户端主动选算法状态是对象内部状态自动决定行为。最典型的例子是订单状态待支付、已支付、已发货、已取消每个状态一个类状态类自己决定下一步流转。主类不再写几十个 if/else。模板方法模式定义一个流程骨架把变化步骤留给子类。比如“准备饮品”的流程是固定的煮水、冲泡、加料。子类决定加茶还是加咖啡。框架代码里特别多Spring 的JdbcTemplate就是模板方法它帮你管理连接、执行 SQL、处理异常只把 SQL 留给你。5.2 观察者、责任链、命令观察者模式解决一对多通知。按钮点击监听、股票价格变化通知、订单状态广播都是观察者。Java 的PropertyChangeListener、C# 的event关键字都是语言层面已经内置好的观察者。你写业务时只要遇到“一个变化要让多个模块响应”就可以考虑它。责任链模式让请求沿着链条传递每个节点决定处理还是放行。审批流、日志过滤器、Servlet Filter都是责任链。好处是解耦发送者和处理者坏处是链太长时排查链路很痛苦所以我一般会控制节点数量并打印清晰的调用日志。命令模式把请求封装成对象。编辑器里的撤销功能是经典场景每个操作都是一个 Command执行完入栈撤销时反向执行。命令模式还能支持操作队列、操作日志适合做“可回放”的系统。5.3 剩下的迭代器、中介者、备忘录、解释器、访问者怎么记这五个属于“特定场景专用”平时用得不多但考试会考。迭代器把遍历和容器解耦。客户端不知道集合内部是数组还是链表也能一个个遍历。C STL 的 iterator、Java 的 Iterator 都是。中介者多个对象直接交互变成通过中间人交互。聊天室是典型客户端不直接互聊都发给服务器转发。备忘录保存对象某个时刻的状态用于恢复。注意保存和恢复都要控制权限别把内部状态全部对外暴露。解释器定义一种语言并解释它。编译器、规则引擎会用到。除非你在做 DSL否则不建议业务代码主动用它。访问者数据结构和操作分离。给元素集合增加新操作时不用改每个元素类而是加一个 Visitor。代价是新增元素类型时所有 Visitor 都要改所以只在结构稳定、操作常变的场景用。行为型模式的口诀可以这样串责命解迭中备观状策模访。对应责任链、命令、解释器、迭代器、中介者、备忘录、观察者、状态、策略、模板方法、访问者。配合前面的创建型、结构型口诀正好凑齐 23 个软考和期末的分类题都有救。6. 从 Java、C、C# 到 MVC同一个模式在不同语言里的落地差异6.1 Java设计模式已经被框架吸收Java 世界里现在很少需要你手写设计模式因为框架和语言已经替你做了。Spring 里到处是模式Bean 默认是单例BeanFactory 是工厂AOP 是动态代理JdbcTemplate、RestTemplate 是模板方法事件监听是观察者。你去面试“Java 设计模式”相关的问题与其背 23 个定义不如先把 Spring 里用了哪些模式说清楚含金量高得多。另外Java 8 之后的 Lambda 和函数式接口让策略模式写法轻量了很多。以前要写一个接口、一个实现类现在经常一个 Lambda 表达式就解决了。模式思想没变表达成本大幅下降。6.2 C资源管理优先部分模式写法完全不同C 里设计模式要时刻想着资源管理因为裸指针和手动内存管理会让模式变形。单例最简单可靠的写法是 C11 的局部静态变量线程安全由语言保证拷贝构造要 delete 掉。组合、聚合关系中强烈建议用unique_ptr或shared_ptr表达所有权这样对象析构时资源能自动释放。C 的策略模式也不一定要写抽象基类。可以用模板在编译期选择策略性能更高但代码可读性会下降也可以用std::function在运行期替换灵活性和 Java 接口类似。C 里常用的设计模式反而更偏“惯用法”而不是 GOF 类图比如 RAII、Pimpl、类型擦除。RAII 虽然不是 GOF 模式但在 C 里是所有模式的地基资源获取即初始化析构函数负责释放。6.3 C#语言语法糖让模式实现更轻C# 对设计模式非常友好。单例用LazyT就够观察者直接可以用event关键字策略可以用Func、Action委托LINQ 本身就是迭代器模式加链式调用IDisposable加using语法接近 RAII。所以 C# 开发者写设计模式最怕的不是不会而是重复造轮子。你要先问自己这个模式是不是已经被语言或框架覆盖了例如要遍历集合直接用foreach和 LINQ没必要自己实现迭代器。模式的价值在业务层不在基础设施层。6.4 MVC 是架构模式不是 GOF 模式MVC 经常被归进设计模式讨论但它属于架构模式比 GOF 设计模式大一个层级。MVC 内部也用了设计模式视图和模型通过观察者保持同步控制器可以看作策略视图树可以看作组合模式。所以面试时被问到“MVC 和设计模式什么关系”别只说三层结构把观察者、策略、组合这几个关联点讲出来面试官会觉得你是真的理解而不是背概念。顺带提一下最近网上那个“体验「设计创意模式」”的热词。它更多是产品设计、创意方法领域的说法强调把用户洞察转成可复制的创新套路。它和软件里的 GOF 设计模式不是一个体系但底层逻辑同源把成功经验沉淀成可复用的套路降低从 0 到 1 的决策成本。你写简历或者面试提到“设计模式”默认还是指 GOF 这套别被概念混淆带偏。7. 软考、期末、大作业、面试怎么答题才拿分7.1 软考设计模式速记场景关键词优先软考上午题常给你一段场景描述问你该用哪种模式或者给出模式分类。我的速记方法是记“场景关键词”而不是记完整定义。场景关键词优先选的模式接口不兼容、老系统对接适配器对象只能一个单例创建对象类型不固定工厂方法一族配套产品抽象工厂算法可以替换策略对象状态自动流转状态一对多通知观察者树形目录、菜单组合动态增强功能装饰器不直接访问目标代理多层次请求处理责任链看到场景先判断变化点再把模式名写出来正确率会高很多。下午案例题如果让你补类图就往“角色”上靠模式由哪些类组成、类之间是什么关系、哪个类负责接口定义、哪个类负责实现。7.2 期末和设计模式大作业别堆模式讲清楚“为什么”期末画 UML 类图时要注意关系符号继承是实线空心三角实现是虚线空心三角依赖是虚线箭头关联是实线箭头聚合是空心菱形组合是实心菱形。类图回答的是“谁和谁是什么关系”画之前先想清楚。设计模式大作业我见过太多同学为了展示能力硬塞八个模式进一个系统最后老师看完一头雾水。我的建议是选一个具体小业务比如网上订餐挑三到四个模式就够了菜品创建用工厂模式菜单类型增加时不需要改客户端订单状态通知用观察者模式下单后自动通知后厨、推送用户、生成积分优惠计算用策略模式满减、折扣、VIP 价可以自由切数据访问用模板方法统一处理连接、事务、异常。每个模式都要解释“如果没有它改动会发生在哪里”。你只要把这个逻辑讲清楚分就不会低。7.3 面试题怎么答才有说服力面试里高频的设计模式问题有单例有几种写法工厂和抽象工厂区别策略和状态区别代理和装饰器区别Spring 中用了哪些设计模式如何设计一个可扩展的优惠系统。答题建议用三步框架讲场景什么情况下会出现这个问题讲方案我选择哪个模式核心结构是什么讲权衡这个模式带来什么好处代价是什么。比如问到策略模式不要只说“把算法封装起来”。你可以说优惠规则经常变如果写死在业务类里每次上线都改老代码测试面很大。我用策略接口加实现类隔离变化新增规则只需要加类代价是会多出不少类规则很少时不值得。回答时主动说缺点特别加分。因为它能证明你不是背答案而是真的在工程里权衡过。8. 什么时候故意不用设计模式以及我的实战习惯8.1 模式是有成本的每引入一个模式就多一层间接。间接能解耦也会让新手看不懂。项目只有两百行代码一个 if/else 就能表达清楚的时候上策略模式就是过度设计。过度设计有几个信号类数量开始明显多于业务实体为了“统一”而造的抽象没有实际使用方改一个简单逻辑要跨五六个文件团队新人看代码时不停问“这个接口为什么存在”。出现这些信号通常不是模式不够多而是模式用重了。8.2 我自己的三条底线第一第一次写代码时用最直白的方式让需求先跑通。第二次遇到同一个变化点再考虑抽象。如果第三次又在同一个位置改那就说明这里需要模式了。我把它叫“三次规则”。第二选型先问变化点。创建方式变用工厂行为算法变用策略接口不匹配用适配器状态流转用状态通知关系用观察者。对准变化点再动手不要看哪个模式名字好听。第三模式是给下一个改代码的人用的。如果团队里没人能看懂这个模式就是负债。写注释时也别堆“这里是策略模式”而要写“这里用策略是因为优惠算法经常独立变化”。解释意图比解释类图有用得多。如果只从这篇里带走一句话我希望是设计模式不是为了显得专业而是为了让三个月后的你、换班的同事、后来接手的陌生人改代码时少掉几根头发。我也是在真正被自己的代码坑过几次之后才彻底想明白这件事的。