GOF23钟设计模式的贡献创建型模式回答对象从哪里来解决构建复杂耦合和扩展性问题模式名称核心目的工程视角解释类比工厂方法模式定义一个创建对象的接口让子类决定实例化哪一个类将对象的创建延迟到子类符合开闭原则新增产品无需修改已有代码汽车制造商根据不同订单生产不同型号的汽车抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口保证产品族的一致性便于整套更换产品系列如更换数据库厂商电器工厂生产同一品牌的全套家电产品建造者模式将复杂对象的构建与其表示分离分步骤构造对象允许通过相同构建过程获得不同内部表示建筑工人按照同一套图纸建造不同装修风格的房屋原型模式通过拷贝现有实例来创建新对象避免重复的初始化开销提高对象创建效率复印机通过原件制作多份复印件单例模式保证一个类仅有一个实例并提供全局访问点节省系统资源常用于配置管理、连接池等场景一个国家只能有一个最高行政长官结构型模式回答对象如何组合解决系统模块间的连接方式和复杂性问题模式名称核心目的工程视角解释类比适配器模式将一个类的接口转换成客户期望的另一个接口解决接口不兼容问题使原本无法协同工作的类可以合作电源转换插头让中国电器在美国插座上使用桥接模式将抽象部分与实现部分分离解耦抽象与实现两者可独立演化减少子类爆炸遥控器和电视机独立设计通过红外信号协作组合模式将对象组合成树形结构以表示“部分-整体”层次统一对待单个对象和组合对象简化客户端代码逻辑文件夹中可以包含文件或其他文件夹装饰器模式动态地给对象添加额外职责相比继承更加灵活可在运行时增减功能给手机贴上防窥膜或戴上保护壳以增强功能外观模式为子系统提供一个统一的访问接口屏蔽系统复杂性降低客户端与子系统间的耦合度餐厅前台统一接待无需顾客自己找厨师和后厨享元模式通过共享技术支持大量细粒度对象复用已有对象减少内存占用提升性能图书馆通过有限的几本《哈利波特》满足上千读者借阅代理模式为对象提供一种代理以控制访问在访问对象时引入间接层用于权限控制、延迟加载等明星通过经纪人处理商务合作行为型模式回答对象如何协作解决职责划分、耦合度和可扩展业务流程问题模式名称核心目的工程视角解释类比责任链模式使多个对象都有机会处理请求将请求的发送者和接收者解耦形成链式处理公司请假审批流程从组长报到CEO直至有人批准命令模式将请求封装为一个对象支持请求的排队、日志记录及撤销重做操作餐厅服务员将顾客点餐写成订单交给厨房制作解释器模式给定一门语言定义其文法的表示用于实现简单的语法解析器或规则引擎翻译官将英文句子翻译成对应的中文含义迭代器模式提供一种方法顺序访问聚合对象中的元素隐藏集合的内部结构统一遍历方式书签帮我们一页页翻书无需关心书的装订方式中介者模式用一个中介对象封装一系列对象交互减少对象间的直接引用降低系统耦合度机场塔台协调飞机起降避免飞机间直接通信备忘录模式在不破坏封装性的前提下保存对象状态实现状态的快照与恢复常用于回滚机制游戏存档功能失败后可以从上一个存档点重启观察者模式定义对象间的一对多依赖关系实现事件驱动机制状态变化时自动通知所有依赖者微信公众号发布文章后自动推送给所有订阅者状态模式允许对象在内部状态改变时改变行为将状态转换逻辑分散到不同状态类中消除大量条件判断电梯门根据“开门”或“关门”状态响应不同按钮策略模式定义一系列算法并使其可互换使算法独立于使用它的客户而变化便于切换算法导航软件提供“最快路线”、“躲避拥堵”等策略模板方法模式定义算法骨架将步骤延迟到子类复用算法结构子类只需实现特定的可变步骤考试试卷规定了题目和格式考生只需填写答案访问者模式将对数据结构的操作与数据结构分离在不修改元素类的前提下定义作用于元素的新操作医生对病人进行体检不同科室医生执行不同检查框架的力量在开始我们一名开发者想要向另一名开发者解释自己的设计时他必须画图编写伪代码举例说明费心口舌但却可能词无表意但现在如果我们学习了设计模式他只需要说这里使用了观察者模式对方就会立刻心领神会。他再说这里我们要使用工厂模式和策略模式就可以把不同支付方式的逻辑解偶。如果对方也懂设计模式那么就可以迅速在抽象层面达到共识沟通成本大幅度下降。设计模式引导开发者围绕以下问题展开思考现在到底卡在哪里创建复杂类太多依赖关系紊乱功能难以扩展用了这个设计模式中谁和谁解偶了使用者与创建者解偶抽象与实现解偶数据与操作解偶将来要改动可以只改哪一小块只更换策略只添加一个装饰器只添加一个工厂方法四大革命范式MVC// Model —— 数据与业务逻辑 class UserModel { private String name; private int age; public void updateProfile(String name, int age) { this.name name; this.age age; notifyObservers(); // 观察者模式的应用 } } // View —— 展示层 class UserView { public void render(UserModel model) { System.out.println(Name: model.getName()); System.out.println(Age: model.getAge()); } } // Controller —— 控制层 class UserController { private UserModel model; private UserView view; public void handleUserInput(String name, int age) { model.updateProfile(name, age); view.render(model); } }MVC 的成功在于它第一次让开发者意识到复杂的应用可以 “分层” 设计。数据是数据展示是展示控制是控制。这种分离不仅让代码更清晰更重要的是让不同的人可以并行工作——设计师专注于 View业务专家专注于 Model架构师协调 Controller。依赖反转传统的编程方式是我需要什么创建什么class OrderService { private DatabaseConnection db new MySQLConnection(); // 硬编码依赖 private EmailService email new SMTPEmailService(); // 硬编码依赖 public void processOrder(Order order) { db.save(order); email.send(order.getCustomerEmail(), Order confirmed); } }而IOC是告诉我你需要什么我来为你准备class OrderService { Autowired private DatabaseConnection db; // 注入的依赖 Autowired private EmailService email; // 注入的依赖 public void processOrder(Order order) { db.save(order); email.send(order.getCustomerEmail(), Order confirmed); } }这让软件开发从 “手工艺雕刻” 变成了 “工业化组装”。我们不再是在写 “死代码”而是在编排Wiring组件。只要接口对得上任何组件都可以替换。这种 “组件可插拔” 的思想为后来微服务的兴起奠定了基础也为今天 Agent 系统中 “工具的动态挂载” 埋下了伏笔——毕竟Agent 选择策略 / 工具的过程本质上就是一种动态的依赖注入。行为可配置策略模式的广泛应用让“算法”成为可替换的“零件”。如何理解这句话先来看一段通过 if-else 语句实现的传统代码。// 传统方式丑陋的 if-else 语句 class PriceCalculator { public double calculate(Customer customer, double amount) { if (customer.getType() CustomerType.REGULAR) { return amount * 0.95; } else if (customer.getType() CustomerType.VIP) { return amount * 0.80; } else if (customer.getType() CustomerType.SUPER_VIP) { return amount * 0.70; } return amount: }在 if-else 语句的世界里程序的行为在编译的那一刻就被锁死了。但在策略模式的世界里对象的行为可以在运行时发生改变。// 策略模式优雅的多态 interface PricingStrategy { double calculate(double amount); } class RegularPricing implements PricingStrategy { public double calculate(double amount) { return amount * 0.95; } } class VIPPricing implements PricingStrategy { public double calculate(double amount) { return amount * 0.80; } } // 行为完全可配置 class PriceCalculator { private PricingStrategy strategy; // 请注意 setStrategy 这个方法 public void setStrategy(PricingStrategy strategy) { this.strategy strategy; } public double calculate(double amount) { return strategy.calculate(amount); } }从代码到图形UML(Unified Modeling Language, 统一建模语言)作为软件设计师的“世界语”, 提供了一系列标准化的类图、序列图、状态图……软件设计第一次可以在不编写一行代码的情况下被完整表达。SOLID面向对象设计原则单一职责原则Single Responsibility PrincipleSRP一个类仅承担一项职责。开闭原则对扩展开放对修改关闭。里氏替换原则Liskov Substitution PrincipleLSP子类必须能够替代其父类而不影响程序的正确性。接口隔离原则Interface Segregation PrincipleISP不强迫客户端依赖其用不到的接口。依赖倒置原则Dependency Inversion PrincipleDIP应依赖抽象而非具体实现。GOF的落败当确定性遇到不确定性Web 2.0 带来了用户爆炸用户数从千人级跃升至亿人级范围从固定用户扩展到全球用户服务时间从朝九晚五变为 7×24 小时不间断。分布式成为常态系统架构从单机演进到数千台服务器通信方式从同步调用转向异步消息事务模型从 ACID转向 BASE 一致性策略从强一致性转为最终一致性。敏捷思想改变了开发节奏发布频率从年度变为每日部署开发模式从瀑布式转向持续迭代设计原则从“详尽完备”变为“够用就好”架构方式从预先设计转向演进式设计。移动互联网改变了交互模式输入方式从键盘、鼠标变为触摸、手势显示设备从大屏幕转向小屏幕网络连接从有线变为无线使用场景从固定位置变为随时随地。ACID是Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性的首字母缩写主要用于传统的数据库事务处理强调数据的强一致性和事务的完整性。BASE是Basically Available基本可用、Soft state软状态、Eventually consistent最终一致性的缩写主要用于分布式系统和高并发场景强调系统的可用性和伸缩性允许数据在一定时间内出现短暂的不一致性。三个不确定性规模不确定行为不确定需求不确定
第1章：从结构到智能，设计模式的世纪旅程
发布时间：2026/6/8 2:41:58
GOF23钟设计模式的贡献创建型模式回答对象从哪里来解决构建复杂耦合和扩展性问题模式名称核心目的工程视角解释类比工厂方法模式定义一个创建对象的接口让子类决定实例化哪一个类将对象的创建延迟到子类符合开闭原则新增产品无需修改已有代码汽车制造商根据不同订单生产不同型号的汽车抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口保证产品族的一致性便于整套更换产品系列如更换数据库厂商电器工厂生产同一品牌的全套家电产品建造者模式将复杂对象的构建与其表示分离分步骤构造对象允许通过相同构建过程获得不同内部表示建筑工人按照同一套图纸建造不同装修风格的房屋原型模式通过拷贝现有实例来创建新对象避免重复的初始化开销提高对象创建效率复印机通过原件制作多份复印件单例模式保证一个类仅有一个实例并提供全局访问点节省系统资源常用于配置管理、连接池等场景一个国家只能有一个最高行政长官结构型模式回答对象如何组合解决系统模块间的连接方式和复杂性问题模式名称核心目的工程视角解释类比适配器模式将一个类的接口转换成客户期望的另一个接口解决接口不兼容问题使原本无法协同工作的类可以合作电源转换插头让中国电器在美国插座上使用桥接模式将抽象部分与实现部分分离解耦抽象与实现两者可独立演化减少子类爆炸遥控器和电视机独立设计通过红外信号协作组合模式将对象组合成树形结构以表示“部分-整体”层次统一对待单个对象和组合对象简化客户端代码逻辑文件夹中可以包含文件或其他文件夹装饰器模式动态地给对象添加额外职责相比继承更加灵活可在运行时增减功能给手机贴上防窥膜或戴上保护壳以增强功能外观模式为子系统提供一个统一的访问接口屏蔽系统复杂性降低客户端与子系统间的耦合度餐厅前台统一接待无需顾客自己找厨师和后厨享元模式通过共享技术支持大量细粒度对象复用已有对象减少内存占用提升性能图书馆通过有限的几本《哈利波特》满足上千读者借阅代理模式为对象提供一种代理以控制访问在访问对象时引入间接层用于权限控制、延迟加载等明星通过经纪人处理商务合作行为型模式回答对象如何协作解决职责划分、耦合度和可扩展业务流程问题模式名称核心目的工程视角解释类比责任链模式使多个对象都有机会处理请求将请求的发送者和接收者解耦形成链式处理公司请假审批流程从组长报到CEO直至有人批准命令模式将请求封装为一个对象支持请求的排队、日志记录及撤销重做操作餐厅服务员将顾客点餐写成订单交给厨房制作解释器模式给定一门语言定义其文法的表示用于实现简单的语法解析器或规则引擎翻译官将英文句子翻译成对应的中文含义迭代器模式提供一种方法顺序访问聚合对象中的元素隐藏集合的内部结构统一遍历方式书签帮我们一页页翻书无需关心书的装订方式中介者模式用一个中介对象封装一系列对象交互减少对象间的直接引用降低系统耦合度机场塔台协调飞机起降避免飞机间直接通信备忘录模式在不破坏封装性的前提下保存对象状态实现状态的快照与恢复常用于回滚机制游戏存档功能失败后可以从上一个存档点重启观察者模式定义对象间的一对多依赖关系实现事件驱动机制状态变化时自动通知所有依赖者微信公众号发布文章后自动推送给所有订阅者状态模式允许对象在内部状态改变时改变行为将状态转换逻辑分散到不同状态类中消除大量条件判断电梯门根据“开门”或“关门”状态响应不同按钮策略模式定义一系列算法并使其可互换使算法独立于使用它的客户而变化便于切换算法导航软件提供“最快路线”、“躲避拥堵”等策略模板方法模式定义算法骨架将步骤延迟到子类复用算法结构子类只需实现特定的可变步骤考试试卷规定了题目和格式考生只需填写答案访问者模式将对数据结构的操作与数据结构分离在不修改元素类的前提下定义作用于元素的新操作医生对病人进行体检不同科室医生执行不同检查框架的力量在开始我们一名开发者想要向另一名开发者解释自己的设计时他必须画图编写伪代码举例说明费心口舌但却可能词无表意但现在如果我们学习了设计模式他只需要说这里使用了观察者模式对方就会立刻心领神会。他再说这里我们要使用工厂模式和策略模式就可以把不同支付方式的逻辑解偶。如果对方也懂设计模式那么就可以迅速在抽象层面达到共识沟通成本大幅度下降。设计模式引导开发者围绕以下问题展开思考现在到底卡在哪里创建复杂类太多依赖关系紊乱功能难以扩展用了这个设计模式中谁和谁解偶了使用者与创建者解偶抽象与实现解偶数据与操作解偶将来要改动可以只改哪一小块只更换策略只添加一个装饰器只添加一个工厂方法四大革命范式MVC// Model —— 数据与业务逻辑 class UserModel { private String name; private int age; public void updateProfile(String name, int age) { this.name name; this.age age; notifyObservers(); // 观察者模式的应用 } } // View —— 展示层 class UserView { public void render(UserModel model) { System.out.println(Name: model.getName()); System.out.println(Age: model.getAge()); } } // Controller —— 控制层 class UserController { private UserModel model; private UserView view; public void handleUserInput(String name, int age) { model.updateProfile(name, age); view.render(model); } }MVC 的成功在于它第一次让开发者意识到复杂的应用可以 “分层” 设计。数据是数据展示是展示控制是控制。这种分离不仅让代码更清晰更重要的是让不同的人可以并行工作——设计师专注于 View业务专家专注于 Model架构师协调 Controller。依赖反转传统的编程方式是我需要什么创建什么class OrderService { private DatabaseConnection db new MySQLConnection(); // 硬编码依赖 private EmailService email new SMTPEmailService(); // 硬编码依赖 public void processOrder(Order order) { db.save(order); email.send(order.getCustomerEmail(), Order confirmed); } }而IOC是告诉我你需要什么我来为你准备class OrderService { Autowired private DatabaseConnection db; // 注入的依赖 Autowired private EmailService email; // 注入的依赖 public void processOrder(Order order) { db.save(order); email.send(order.getCustomerEmail(), Order confirmed); } }这让软件开发从 “手工艺雕刻” 变成了 “工业化组装”。我们不再是在写 “死代码”而是在编排Wiring组件。只要接口对得上任何组件都可以替换。这种 “组件可插拔” 的思想为后来微服务的兴起奠定了基础也为今天 Agent 系统中 “工具的动态挂载” 埋下了伏笔——毕竟Agent 选择策略 / 工具的过程本质上就是一种动态的依赖注入。行为可配置策略模式的广泛应用让“算法”成为可替换的“零件”。如何理解这句话先来看一段通过 if-else 语句实现的传统代码。// 传统方式丑陋的 if-else 语句 class PriceCalculator { public double calculate(Customer customer, double amount) { if (customer.getType() CustomerType.REGULAR) { return amount * 0.95; } else if (customer.getType() CustomerType.VIP) { return amount * 0.80; } else if (customer.getType() CustomerType.SUPER_VIP) { return amount * 0.70; } return amount: }在 if-else 语句的世界里程序的行为在编译的那一刻就被锁死了。但在策略模式的世界里对象的行为可以在运行时发生改变。// 策略模式优雅的多态 interface PricingStrategy { double calculate(double amount); } class RegularPricing implements PricingStrategy { public double calculate(double amount) { return amount * 0.95; } } class VIPPricing implements PricingStrategy { public double calculate(double amount) { return amount * 0.80; } } // 行为完全可配置 class PriceCalculator { private PricingStrategy strategy; // 请注意 setStrategy 这个方法 public void setStrategy(PricingStrategy strategy) { this.strategy strategy; } public double calculate(double amount) { return strategy.calculate(amount); } }从代码到图形UML(Unified Modeling Language, 统一建模语言)作为软件设计师的“世界语”, 提供了一系列标准化的类图、序列图、状态图……软件设计第一次可以在不编写一行代码的情况下被完整表达。SOLID面向对象设计原则单一职责原则Single Responsibility PrincipleSRP一个类仅承担一项职责。开闭原则对扩展开放对修改关闭。里氏替换原则Liskov Substitution PrincipleLSP子类必须能够替代其父类而不影响程序的正确性。接口隔离原则Interface Segregation PrincipleISP不强迫客户端依赖其用不到的接口。依赖倒置原则Dependency Inversion PrincipleDIP应依赖抽象而非具体实现。GOF的落败当确定性遇到不确定性Web 2.0 带来了用户爆炸用户数从千人级跃升至亿人级范围从固定用户扩展到全球用户服务时间从朝九晚五变为 7×24 小时不间断。分布式成为常态系统架构从单机演进到数千台服务器通信方式从同步调用转向异步消息事务模型从 ACID转向 BASE 一致性策略从强一致性转为最终一致性。敏捷思想改变了开发节奏发布频率从年度变为每日部署开发模式从瀑布式转向持续迭代设计原则从“详尽完备”变为“够用就好”架构方式从预先设计转向演进式设计。移动互联网改变了交互模式输入方式从键盘、鼠标变为触摸、手势显示设备从大屏幕转向小屏幕网络连接从有线变为无线使用场景从固定位置变为随时随地。ACID是Atomicity原子性、Consistency一致性、Isolation隔离性、Durability持久性的首字母缩写主要用于传统的数据库事务处理强调数据的强一致性和事务的完整性。BASE是Basically Available基本可用、Soft state软状态、Eventually consistent最终一致性的缩写主要用于分布式系统和高并发场景强调系统的可用性和伸缩性允许数据在一定时间内出现短暂的不一致性。三个不确定性规模不确定行为不确定需求不确定
