简介这份《大话设计模式复习》文档面向具备一定面向对象编程基础、工作1至3年的研发人员系统梳理设计模式的核心知识体系。内容从设计模式的定义、分类、特点与应用场景切入详细讲解单一职责、开放-封闭、依赖倒转、里氏代换、迪米特法则、合成/聚合及接口隔离七大设计原则并深入剖析抽象工厂、策略、外观、适配器、组合、单例、中介者七种常用模式以及其余十五种模式每种均配以定义、UML类图、基础代码与实例。文档还横向对比不同模式的差异总结模式选择的关键维度并附练习题与模拟试卷辅助巩固。资源为单个docx文件压缩包约3.66MB已有191人学习。读者可借此理解模式适用场景提升代码可维护性与扩展性并在实际项目中做出更合理的设计选择。1. 设计模式到底在讲什么从“每次改需求都像拆炸弹”说起你有没有过这种经历接手一个项目想加一个小功能结果发现牵一发动全身改完这里崩那里最后不得不把整个模块重写。这种“改不动”的痛苦根源往往不在代码写得丑而在于结构没设计好。设计模式就是前人踩了无数坑之后总结出的一套“结构配方”——它不教你写某一行代码而是告诉你面对某类反复出现的问题时类和对象该怎么摆、职责该怎么分。通俗地说设计模式就像做菜时的“经典菜谱”红烧肉有红烧肉的做法糖醋排骨有糖醋排骨的做法你不需要每次从零发明照着菜谱来味道稳定别人也看得懂。在软件工程和面向对象编程里这套“菜谱”被反复验证、分类编目最终形成了 23 种经典模式分成创建型、结构型、行为型三大类。搞懂它们你就能在 Java 这类语言里写出可维护、可扩展、可复用的代码而不是每次需求一变就翻车。2. 为什么需要设计模式七个原则才是真正的底层逻辑2.1 设计原则不是口号是“避坑指南”很多人一上来就背 23 种模式结果用的时候生搬硬套反而把代码搞复杂了。其实模式是“术”原则才是“道”。这份资料里重点讲了七大原则它们才是判断“该不该用模式、用哪个模式”的依据。单一职责原则SRP说的是一个类只干一件事。比如计算器里的加法和减法各自独立成类而不是塞进一个“运算类”里。这样改加法不会影响减法测试也好写。开放-封闭原则OCP更关键软件实体应该对扩展开放、对修改关闭。翻译成大白话就是加新功能时最好新增代码而不是去改老代码。策略模式就是典型例子——新增一种折扣算法只需要写一个新的策略类原来的策略接口和上下文都不用动。依赖倒转原则DIP要求高层模块和低层模块都依赖抽象而不是高层依赖低层。比如工厂模式里客户端只认抽象产品接口不认具体产品类这样换一套产品实现客户端代码一行不用改。里氏代换原则LSP说的是子类必须能替换父类且行为不变。正方形继承矩形在数学上成立但在代码里如果正方形强制宽高相等替换矩形时面积计算就可能出问题这就是违反 LSP 的经典案例。迪米特法则LOD叫“最少知识原则”一个类对另一个类知道得越少越好。中介者模式就是它的化身同事类之间不直接调用全部通过中介者转发耦合度直线下降。合成/聚合原则CARP建议尽量用组合而不是继承来扩展功能装饰模式就是靠组合装饰器与组件而不是继承出一堆子类。接口隔离原则ISP则要求把大接口拆成小接口比如“动物”接口拆成“飞行动物”“陆地动物”避免类被迫实现用不到的方法。2.2 原则和模式的关系先有判断再有选择这七个原则不是孤立的它们互相配合。比如你要设计一个可移植的数据访问程序支持不同数据库那么依赖倒转原则告诉你依赖抽象工厂接口合成/聚合原则告诉你用组合把产品对象拼起来开放-封闭原则提醒你新增产品族时可能会违反它——因为抽象工厂模式增加新产品等级结构需要修改所有具体工厂。你看原则帮你预判了模式的代价。所以学设计模式正确的顺序是先理解这些原则再去看每个模式是怎么体现或权衡这些原则的。这份资料把七大原则放在模式分析之前就是这个用意。它让你带着“为什么这样设计”的问题去读后面的模式而不是死记 UML 类图。3. 创建型模式对象怎么“生”出来才不乱3.1 简单工厂、工厂方法、抽象工厂三兄弟到底差在哪创建型模式关注对象的创建方式最容易被搞混的就是工厂家族。简单工厂模式是一个工厂类根据参数决定创建哪种产品比如Factory.createProduct(A)。它简单但新增产品要改工厂类违反开放-封闭原则。工厂方法模式把创建延迟到子类每个具体工厂只负责一种产品新增产品只需新增工厂符合开放-封闭。抽象工厂模式则是为创建一组相关或依赖的对象族提供接口比如不同数据库工厂创建 User 和 Department 对象一个工厂负责一个产品族。用表格对比更清楚模式创建对象新增产品新增产品族符合 OCP简单工厂单一产品改工厂类不适用否工厂方法单一产品新增工厂类不适用是抽象工厂产品族改抽象工厂和所有具体工厂新增具体工厂部分抽象工厂的典型实例是可移植数据访问程序IFactory接口声明CreateUser()和CreateDepartment()SqlServerFactory和AccessFactory分别实现客户端只依赖IFactory。这样换数据库时只需换一个工厂实例业务代码不动。但如果你要新增一种产品比如新增CreateOrder()所有具体工厂都得改这就是它违反开放-封闭原则的地方。3.2 单例、建造者、原型创建方式的另类选择单例模式保证一个类只有一个实例并提供全局访问点。它适合配置管理、连接池这类场景但要注意多线程下的线程安全以及它可能带来的全局状态问题。建造者模式把复杂对象的构建与表示分离适合参数多、构建步骤固定的对象比如组装一台电脑可以分步设置 CPU、内存、硬盘最后build()。原型模式通过复制现有对象来创建新对象适合创建成本高、但状态可复制的场景比如一个初始化很慢的对象直接克隆比重新 new 快得多。这三个模式和工厂家族的区别在于工厂关注“创建什么”建造者关注“怎么一步步创建”原型关注“从现有对象复制”。单例则关注“创建几个”。理解这个维度就不会混用。4. 结构型与行为型把类和对象摆对位置4.1 适配器、装饰器、代理三个“包装”模式的区别结构型模式关注类和对象的组合。适配器、装饰器、代理都涉及“包装”一个对象但目的完全不同。适配器模式是让接口不兼容的类能一起工作比如一个旧系统的接口和新系统对不上加个适配器转换一下。装饰器模式是在不改变原类的情况下动态添加功能比如给一个组件层层包裹装饰器每层加一点行为。代理模式是控制对对象的访问比如远程代理、虚拟代理、保护代理客户端以为在直接调用其实中间隔了一层。用一句话区分适配器是“转换接口”装饰器是“增强功能”代理是“控制访问”。组合模式把对象组合成树形结构表示“部分-整体”的层次比如文件系统里文件夹和文件可以统一处理。外观模式为子系统提供统一的高层接口让客户端不用跟一堆类打交道。桥接模式把抽象和实现分离让它们可以独立变化。享元模式通过共享细粒度对象来节省内存适合大量相似对象的场景。4.2 策略、状态、观察者、中介者行为型模式怎么选行为型模式关注对象之间的交互和职责分配。策略模式和状态模式结构很像但意图不同策略模式是客户端主动选择算法算法之间互不关心状态模式是对象内部状态改变时自动切换行为状态之间可能有转换关系。比如商场收银系统用策略模式不同折扣策略由客户端选择而一个订单对象的状态从“待支付”到“已支付”再到“已发货”用状态模式更自然。观察者模式和中介者模式也容易混。观察者模式是一对多的依赖关系当一个对象状态改变所有依赖它的对象都收到通知比如事件监听。中介者模式是多对多的交互通过中介者协调同事类之间不直接通信比如聊天室里的用户都通过服务器转发消息。责任链模式把请求沿着处理链传递直到有一个处理者处理它比如审批流程。模板方法模式在父类定义算法骨架子类实现具体步骤。命令模式把请求封装成对象支持撤销、队列等操作。备忘录模式保存对象状态以便恢复迭代器模式遍历集合访问者模式在不改变元素类的前提下定义新操作解释器模式处理文法规则。5. 常见误区这些模式你很可能用反了5.1 误区一抽象工厂和工厂方法是一回事易混点两者都叫“工厂”都创建对象。为什么混名字相似UML 结构也有相似之处。怎么区分工厂方法只创建一类对象抽象工厂创建一组相关对象族。抽象工厂的抽象工厂接口里通常有多个创建方法比如createProductA()和createProductB()而工厂方法只有一个createProduct()。如果你只需要创建一种产品用工厂方法如果需要创建多个相互关联的产品用抽象工厂。5.2 误区二策略模式和状态模式可以互换易混点两者都有 Context 和抽象策略/状态接口具体类实现不同行为。为什么混结构几乎一样。怎么区分策略模式的客户端知道所有策略并主动选择策略之间没有依赖状态模式的状态转换通常由状态自身或上下文触发客户端不关心具体状态。策略模式是“选算法”状态模式是“随状态变行为”。如果你发现代码里有一堆 if-else 判断状态然后执行不同逻辑那可能是状态模式该上场了。5.3 误区三适配器和装饰器都是包装随便用易混点两者都持有被包装对象的引用。为什么混都叫 Wrapper。怎么区分适配器改变接口让不兼容的接口能协作装饰器保持接口不变只增强功能。适配器的客户端调用的是适配器的新接口装饰器的客户端调用的是和原组件一样的接口。如果你需要“转换”用适配器如果需要“叠加功能”用装饰器。5.4 误区四单例模式可以随便用易混点单例看起来方便全局访问还能省资源。为什么混初学者觉得“只有一个实例”很安全。怎么区分单例引入全局状态让单元测试变难还可能隐藏依赖关系。如果只是想让某个资源只初始化一次考虑依赖注入而不是单例。单例适合真正需要唯一实例的场景比如配置管理器但不要把它当成万能工具箱。5.5 误区五设计模式用得越多越好易混点学了模式就想到处用觉得不用就落伍。为什么混模式被神化了。怎么区分模式是解决特定问题的工具不是目标。过度使用模式会让代码更复杂、更难懂。比如一个简单的 if-else 能解决的问题硬套策略模式反而增加类数量。先判断问题是否反复出现、是否有扩展需求再决定用不用模式。记住简单是最终目标模式只是通往简单的路径之一。6. 什么时候用、什么时候别用一个真实场景的取舍假设你在做一个商场收银系统需求是支持多种折扣正常收费、满减、打折。一开始你可能写一个CashSuper类里面用 if-else 判断折扣类型。这能跑但每次新增折扣都要改这个类违反开放-封闭原则。这时候策略模式就合适定义CashSuper接口CashNormal、CashReturn、CashRebate分别实现客户端持有一个策略对象运行时切换。新增折扣只需新增策略类不改原有代码。但如果你只是做一个内部小工具折扣规则永远只有一种那用策略模式就是过度设计。直接写死反而更清晰。这就是边界当变化是常态、扩展是刚需时用模式当变化极少、逻辑简单时别用。再比如你要设计一个跨平台的数据访问层支持多种数据库。抽象工厂模式很合适IFactory定义CreateUser()和CreateDepartment()不同数据库工厂实现它。但如果你的系统只连一种数据库且未来也不太可能换那抽象工厂就是多余的直接 new 具体类更省事。我自己的血泪经验是曾经在一个小模块里硬套了观察者模式结果为了通知一个状态变化绕了三层接口调试时追调用链追到怀疑人生。后来我把那个模块重写成直接调用代码量少了一半可读性反而更好。从那以后我每次想用模式之前都强制问自己三个问题这个问题真的会反复出现吗未来扩展的频率有多高不用模式的话最坏情况是什么如果答案都是“还好”那我就选择简单方案。设计模式是工具箱里的扳手不是每颗螺丝都要用扳手拧。希望这份资料能帮你建立判断力知道什么时候该拿起哪个工具什么时候该放下。本文还有配套的精品资源点击获取
简介这份《大话设计模式复习》文档面向具备一定面向对象编程基础、工作1至3年的研发人员系统梳理设计模式的核心知识体系。内容从设计模式的定义、分类、特点与应用场景切入详细讲解单一职责、开放-封闭、依赖倒转、里氏代换、迪米特法则、合成/聚合及接口隔离七大设计原则并深入剖析抽象工厂、策略、外观、适配器、组合、单例、中介者七种常用模式以及其余十五种模式每种均配以定义、UML类图、基础代码与实例。文档还横向对比不同模式的差异总结模式选择的关键维度并附练习题与模拟试卷辅助巩固。资源为单个docx文件压缩包约3.66MB已有191人学习。读者可借此理解模式适用场景提升代码可维护性与扩展性并在实际项目中做出更合理的设计选择。1. 设计模式到底在讲什么从“每次改需求都像拆炸弹”说起你有没有过这种经历接手一个项目想加一个小功能结果发现牵一发动全身改完这里崩那里最后不得不把整个模块重写。这种“改不动”的痛苦根源往往不在代码写得丑而在于结构没设计好。设计模式就是前人踩了无数坑之后总结出的一套“结构配方”——它不教你写某一行代码而是告诉你面对某类反复出现的问题时类和对象该怎么摆、职责该怎么分。通俗地说设计模式就像做菜时的“经典菜谱”红烧肉有红烧肉的做法糖醋排骨有糖醋排骨的做法你不需要每次从零发明照着菜谱来味道稳定别人也看得懂。在软件工程和面向对象编程里这套“菜谱”被反复验证、分类编目最终形成了 23 种经典模式分成创建型、结构型、行为型三大类。搞懂它们你就能在 Java 这类语言里写出可维护、可扩展、可复用的代码而不是每次需求一变就翻车。2. 为什么需要设计模式七个原则才是真正的底层逻辑2.1 设计原则不是口号是“避坑指南”很多人一上来就背 23 种模式结果用的时候生搬硬套反而把代码搞复杂了。其实模式是“术”原则才是“道”。这份资料里重点讲了七大原则它们才是判断“该不该用模式、用哪个模式”的依据。单一职责原则SRP说的是一个类只干一件事。比如计算器里的加法和减法各自独立成类而不是塞进一个“运算类”里。这样改加法不会影响减法测试也好写。开放-封闭原则OCP更关键软件实体应该对扩展开放、对修改关闭。翻译成大白话就是加新功能时最好新增代码而不是去改老代码。策略模式就是典型例子——新增一种折扣算法只需要写一个新的策略类原来的策略接口和上下文都不用动。依赖倒转原则DIP要求高层模块和低层模块都依赖抽象而不是高层依赖低层。比如工厂模式里客户端只认抽象产品接口不认具体产品类这样换一套产品实现客户端代码一行不用改。里氏代换原则LSP说的是子类必须能替换父类且行为不变。正方形继承矩形在数学上成立但在代码里如果正方形强制宽高相等替换矩形时面积计算就可能出问题这就是违反 LSP 的经典案例。迪米特法则LOD叫“最少知识原则”一个类对另一个类知道得越少越好。中介者模式就是它的化身同事类之间不直接调用全部通过中介者转发耦合度直线下降。合成/聚合原则CARP建议尽量用组合而不是继承来扩展功能装饰模式就是靠组合装饰器与组件而不是继承出一堆子类。接口隔离原则ISP则要求把大接口拆成小接口比如“动物”接口拆成“飞行动物”“陆地动物”避免类被迫实现用不到的方法。2.2 原则和模式的关系先有判断再有选择这七个原则不是孤立的它们互相配合。比如你要设计一个可移植的数据访问程序支持不同数据库那么依赖倒转原则告诉你依赖抽象工厂接口合成/聚合原则告诉你用组合把产品对象拼起来开放-封闭原则提醒你新增产品族时可能会违反它——因为抽象工厂模式增加新产品等级结构需要修改所有具体工厂。你看原则帮你预判了模式的代价。所以学设计模式正确的顺序是先理解这些原则再去看每个模式是怎么体现或权衡这些原则的。这份资料把七大原则放在模式分析之前就是这个用意。它让你带着“为什么这样设计”的问题去读后面的模式而不是死记 UML 类图。3. 创建型模式对象怎么“生”出来才不乱3.1 简单工厂、工厂方法、抽象工厂三兄弟到底差在哪创建型模式关注对象的创建方式最容易被搞混的就是工厂家族。简单工厂模式是一个工厂类根据参数决定创建哪种产品比如Factory.createProduct(A)。它简单但新增产品要改工厂类违反开放-封闭原则。工厂方法模式把创建延迟到子类每个具体工厂只负责一种产品新增产品只需新增工厂符合开放-封闭。抽象工厂模式则是为创建一组相关或依赖的对象族提供接口比如不同数据库工厂创建 User 和 Department 对象一个工厂负责一个产品族。用表格对比更清楚模式创建对象新增产品新增产品族符合 OCP简单工厂单一产品改工厂类不适用否工厂方法单一产品新增工厂类不适用是抽象工厂产品族改抽象工厂和所有具体工厂新增具体工厂部分抽象工厂的典型实例是可移植数据访问程序IFactory接口声明CreateUser()和CreateDepartment()SqlServerFactory和AccessFactory分别实现客户端只依赖IFactory。这样换数据库时只需换一个工厂实例业务代码不动。但如果你要新增一种产品比如新增CreateOrder()所有具体工厂都得改这就是它违反开放-封闭原则的地方。3.2 单例、建造者、原型创建方式的另类选择单例模式保证一个类只有一个实例并提供全局访问点。它适合配置管理、连接池这类场景但要注意多线程下的线程安全以及它可能带来的全局状态问题。建造者模式把复杂对象的构建与表示分离适合参数多、构建步骤固定的对象比如组装一台电脑可以分步设置 CPU、内存、硬盘最后build()。原型模式通过复制现有对象来创建新对象适合创建成本高、但状态可复制的场景比如一个初始化很慢的对象直接克隆比重新 new 快得多。这三个模式和工厂家族的区别在于工厂关注“创建什么”建造者关注“怎么一步步创建”原型关注“从现有对象复制”。单例则关注“创建几个”。理解这个维度就不会混用。4. 结构型与行为型把类和对象摆对位置4.1 适配器、装饰器、代理三个“包装”模式的区别结构型模式关注类和对象的组合。适配器、装饰器、代理都涉及“包装”一个对象但目的完全不同。适配器模式是让接口不兼容的类能一起工作比如一个旧系统的接口和新系统对不上加个适配器转换一下。装饰器模式是在不改变原类的情况下动态添加功能比如给一个组件层层包裹装饰器每层加一点行为。代理模式是控制对对象的访问比如远程代理、虚拟代理、保护代理客户端以为在直接调用其实中间隔了一层。用一句话区分适配器是“转换接口”装饰器是“增强功能”代理是“控制访问”。组合模式把对象组合成树形结构表示“部分-整体”的层次比如文件系统里文件夹和文件可以统一处理。外观模式为子系统提供统一的高层接口让客户端不用跟一堆类打交道。桥接模式把抽象和实现分离让它们可以独立变化。享元模式通过共享细粒度对象来节省内存适合大量相似对象的场景。4.2 策略、状态、观察者、中介者行为型模式怎么选行为型模式关注对象之间的交互和职责分配。策略模式和状态模式结构很像但意图不同策略模式是客户端主动选择算法算法之间互不关心状态模式是对象内部状态改变时自动切换行为状态之间可能有转换关系。比如商场收银系统用策略模式不同折扣策略由客户端选择而一个订单对象的状态从“待支付”到“已支付”再到“已发货”用状态模式更自然。观察者模式和中介者模式也容易混。观察者模式是一对多的依赖关系当一个对象状态改变所有依赖它的对象都收到通知比如事件监听。中介者模式是多对多的交互通过中介者协调同事类之间不直接通信比如聊天室里的用户都通过服务器转发消息。责任链模式把请求沿着处理链传递直到有一个处理者处理它比如审批流程。模板方法模式在父类定义算法骨架子类实现具体步骤。命令模式把请求封装成对象支持撤销、队列等操作。备忘录模式保存对象状态以便恢复迭代器模式遍历集合访问者模式在不改变元素类的前提下定义新操作解释器模式处理文法规则。5. 常见误区这些模式你很可能用反了5.1 误区一抽象工厂和工厂方法是一回事易混点两者都叫“工厂”都创建对象。为什么混名字相似UML 结构也有相似之处。怎么区分工厂方法只创建一类对象抽象工厂创建一组相关对象族。抽象工厂的抽象工厂接口里通常有多个创建方法比如createProductA()和createProductB()而工厂方法只有一个createProduct()。如果你只需要创建一种产品用工厂方法如果需要创建多个相互关联的产品用抽象工厂。5.2 误区二策略模式和状态模式可以互换易混点两者都有 Context 和抽象策略/状态接口具体类实现不同行为。为什么混结构几乎一样。怎么区分策略模式的客户端知道所有策略并主动选择策略之间没有依赖状态模式的状态转换通常由状态自身或上下文触发客户端不关心具体状态。策略模式是“选算法”状态模式是“随状态变行为”。如果你发现代码里有一堆 if-else 判断状态然后执行不同逻辑那可能是状态模式该上场了。5.3 误区三适配器和装饰器都是包装随便用易混点两者都持有被包装对象的引用。为什么混都叫 Wrapper。怎么区分适配器改变接口让不兼容的接口能协作装饰器保持接口不变只增强功能。适配器的客户端调用的是适配器的新接口装饰器的客户端调用的是和原组件一样的接口。如果你需要“转换”用适配器如果需要“叠加功能”用装饰器。5.4 误区四单例模式可以随便用易混点单例看起来方便全局访问还能省资源。为什么混初学者觉得“只有一个实例”很安全。怎么区分单例引入全局状态让单元测试变难还可能隐藏依赖关系。如果只是想让某个资源只初始化一次考虑依赖注入而不是单例。单例适合真正需要唯一实例的场景比如配置管理器但不要把它当成万能工具箱。5.5 误区五设计模式用得越多越好易混点学了模式就想到处用觉得不用就落伍。为什么混模式被神化了。怎么区分模式是解决特定问题的工具不是目标。过度使用模式会让代码更复杂、更难懂。比如一个简单的 if-else 能解决的问题硬套策略模式反而增加类数量。先判断问题是否反复出现、是否有扩展需求再决定用不用模式。记住简单是最终目标模式只是通往简单的路径之一。6. 什么时候用、什么时候别用一个真实场景的取舍假设你在做一个商场收银系统需求是支持多种折扣正常收费、满减、打折。一开始你可能写一个CashSuper类里面用 if-else 判断折扣类型。这能跑但每次新增折扣都要改这个类违反开放-封闭原则。这时候策略模式就合适定义CashSuper接口CashNormal、CashReturn、CashRebate分别实现客户端持有一个策略对象运行时切换。新增折扣只需新增策略类不改原有代码。但如果你只是做一个内部小工具折扣规则永远只有一种那用策略模式就是过度设计。直接写死反而更清晰。这就是边界当变化是常态、扩展是刚需时用模式当变化极少、逻辑简单时别用。再比如你要设计一个跨平台的数据访问层支持多种数据库。抽象工厂模式很合适IFactory定义CreateUser()和CreateDepartment()不同数据库工厂实现它。但如果你的系统只连一种数据库且未来也不太可能换那抽象工厂就是多余的直接 new 具体类更省事。我自己的血泪经验是曾经在一个小模块里硬套了观察者模式结果为了通知一个状态变化绕了三层接口调试时追调用链追到怀疑人生。后来我把那个模块重写成直接调用代码量少了一半可读性反而更好。从那以后我每次想用模式之前都强制问自己三个问题这个问题真的会反复出现吗未来扩展的频率有多高不用模式的话最坏情况是什么如果答案都是“还好”那我就选择简单方案。设计模式是工具箱里的扳手不是每颗螺丝都要用扳手拧。希望这份资料能帮你建立判断力知道什么时候该拿起哪个工具什么时候该放下。本文还有配套的精品资源点击获取
