AI 时代为什么还要学设计模式：它真正帮你解决什么问题
- Yajun Wen
- C# , Design pattern
- January 4, 2026
Table of Contents
AI 时代为什么还要学设计模式：它真正帮你解决什么问题
很多人学设计模式时都会有一种感觉：概念很多，名字很专业，真到写业务代码时却不一定天天把这些模式名称挂在嘴边。到了 AI 辅助编程越来越普遍的今天，这个问题会更明显: 既然代码都能生成，为什么还要学设计模式？
我自己的看法是，设计模式最重要的价值从来不是“背答案”，而是帮我们建立组织代码的思维框架。AI 可以帮你更快写出代码，但它不能替你判断抽象层次是不是合理，职责边界是不是清楚，依赖关系是不是已经开始失控。
设计模式分为三大类，其实是一套面向对象代码组织的规则。
- 创建型 关注于对象创建
- 结构型 关注于类与类之间的关系
- 行为型 对象与行为的分离
题外话：曾经哼哧哼哧地学了很久设计模式。如今 AI 时代不再需要手写所有样板代码，但如何组织代码结构、如何做好抽象，这部分经验反而更重要了。
文章初次编写在 https://www.yuque.com/wente-rv9pk/agnnss/uv1o1x
what is 设计模式 ？
高可用的代码，去除冗余的经验法则方式。
并且提供了一套专业词汇用来方便 coder 交流代码
其实这几种设计模式就点像设计里面的四大原则 (重复，对齐，亲密性，对比) 一样随处可见
how to use 设计模式？
我怎样在应用设计模式？
在开发之处做好类图的设计
在开发之后补救，做好类图的设计和重构
类图的设计是按照设计模式的原则进行的
参数签名不同怎么抽象成统一的呢？
参数可以有一个参数结构体或者参数类型
参数名不同或许可以考虑 Apater
设计模式的原则
单一职责原则 (Single Responsibility Principle)： 一个类应该有且仅有一个引起变化的因素
开放封闭原则 (Open/closed Principie)： 对拓展开放，对修改封闭
liskov 替换原则 (Liskov Substitution Principle)： 子类可以替换为他的基类
依赖倒置原则 (Interface Segregation Principle)： 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。抽象不应该依赖细节，细节应该依赖抽象
接口隔离原则 (Dependence Inversion Principle)： 一个类对另一个类的依赖，建立在最小的接口上
SOLID 设计过的软件系统更加的 SOLID 稳固、安全且优雅，更具备拓展性
迪米特法则 (Law of Demeter)： 一个软件实体，应当尽可能少的与其他实体发生相互作用 ?
合成复用原则 ： 尽量使用接口(对象)组合，而不是继承来达到复用的目的
UML 中的箭头
泛化关系 实线空心三角形箭头 代表对非抽象父类的继承关系
实现关系 虚线空心三角形箭头 代表对抽象或者接口的实现关系
聚合关系 实线空心菱形箭头 代表整体由部分组成，部分没有，整体还在
组合关系 实线实心菱形箭头 代表整体由部分组成，部分没有，整体也没余
关联关系 实线 对象之间的关联
有向关联关系 实线箭头 单向的关联关系
依赖关系 虚线箭头 构造方法时传入的依赖对象
心得体会
遵守设计模式比较好的一点就是可以减少耦合，让代码可以高可用，低耦合
在构造类之前确定好类的职责，做好抽象，通常可以用 UML 图来清晰的表达类的关系
同样的，抽象层次需要很好的把控，才方便阅读。
我在实际写代码的过程中，发现一个功能组件的接口，只需要一个函数就够了。
而且在实现这个接口的具体类里面，也要把控好抽象的层次，在实现的函数体中，用高概括分步的子函数去分步实现，从而把控抽象的层数。高屋建瓴，让人一看就知道最高点，和发散出来的细节。
AI 时代怎么重新理解设计模式
如果把设计模式当成要背诵的标准答案，它会显得又重又远；但如果把它当成“组织代码、约束依赖、控制复杂度”的经验总结，它在 AI 时代反而更有现实意义。
AI 可以帮我们更快生成代码，却不会自动保证抽象合理、职责清晰、依赖稳定。真正需要开发者负责的，正是这些更靠近设计层的问题。
总结
设计模式不是为了让代码看起来更高级，而是为了让系统在增长以后依然可读、可改、可扩展。
如果今天让我重新看设计模式，我会更少关注“这个模式叫什么”，更多关注“它解决了什么结构问题”。把这个顺序摆正，设计模式就不会成为死知识，而会变成实际开发里持续有用的判断框架。
参考
https://refactoring.guru/ 重构学习网站
https://www.oodesign.com/ 设计模式的英文网站