设计模式类的拓扑结构描述总纲写这系列的文章就两个目的了解什么是设计模式有哪几种理解什么时候使用这些设计模式结构这里系统的讲一下设计模式围绕下面几个核心的问题1.什么是设计模式2.为什么会有设计模式3.有哪些设计模式4.什么时候可以去使用设计模式具体设计模式类型1创建型模式5种核心解决对象创建过程的灵活性与耦合问题。单例Singleton工厂方法Factory Method抽象工厂Abstract Factory建造者Builder原型Prototype2结构型模式7种核心通过组合类或对象形成更大的结构。适配器Adapter桥接Bridge组合Composite装饰器Decorator外观Facade享元Flyweight代理Proxy3行为型模式11种核心处理算法与对象间职责的分配、通信。责任链Chain of Responsibility命令Command解释器Interpreter迭代器Iterator中介者Mediator备忘录Memento观察者Observer状态State策略Strategy模板方法Template Method访问者Visitor设计模式类的拓扑结构—— 描述总纲写作目的本系列文章围绕两个核心目标展开了解什么是设计模式以及有哪些设计模式理解在什么场景下可以使用这些设计模式结构核心问题本系列将系统性地回答以下四个问题问题简述什么是设计模式定义、本质、价值为什么会有设计模式产生背景、解决什么痛点有哪些设计模式三类23种模式的全景图什么时候用每种模式的适用场景与问题特征一、什么是设计模式设计模式是对软件开发中特定场景下重复出现的类与对象拓扑结构的总结与抽象。通俗地说设计模式就是一套被验证过的、可复用的设计经验。它不是可以直接落地的代码库而是一种解法模板——描述了在什么情况下类和对象应该如何组织、如何交互、如何承接职责从而形成一个可复用的、优雅的结构。从类的拓扑结构这个视角看设计模式本质上是在回答三个问题类与类之间如何连接继承、组合、依赖对象之间如何通信调用、通知、回调职责如何在对象之间分配谁做什么、谁不做什么一句话定义设计模式 特定问题场景下 经过验证的 类/对象拓扑结构二、为什么会有设计模式设计模式的产生源于软件开发中的重复性痛点2.1 核心痛点痛点表现紧耦合修改一处代码牵连一片重复造轮子类似的问题类似的解法每次都重新设计可维护性差代码难以理解、难以扩展、难以测试变动应对能力弱需求一变化架构就崩塌2.2 设计模式解决的三个根本问题封装变化—— 找到代码中可能变化的部分将其隔离面向接口/抽象编程而非实现—— 依赖抽象而非具体类组合优先于继承—— 运行时动态组合行为而非静态绑定2.3 历史背景1994年GoF四人组出版《设计模式可复用面向对象软件的基础》借鉴了建筑学中 Christopher Alexander 的“模式语言”思想总结了23种面向对象设计模式成为软件开发领域的经典三、有哪些设计模式GoF 将23种设计模式分为三大类1创建型模式5种核心关注点对象的创建过程。模式一句话说明关键拓扑特征单例Singleton一个类只有一个实例类持有自己的静态实例工厂方法Factory Method子类决定实例化哪个类继承 多态抽象工厂Abstract Factory创建一系列相关对象多个工厂接口 产品族建造者Builder分步构建复杂对象导向器 建造器分离原型Prototype通过拷贝原型创建对象克隆方法 原型注册表共性将“创建什么对象”与“如何使用对象”解耦。2结构型模式7种核心关注点类与对象的组合方式形成更大的结构。模式一句话说明关键拓扑特征适配器Adapter转换接口让不兼容的类协同工作包装器 接口转换桥接Bridge将抽象部分与实现部分分离抽象类持有实现类引用组合Composite统一对待单个对象和组合对象树形结构 统一接口装饰器Decorator动态添加职责包装器链 透明接口外观Facade为子系统提供统一入口门面类 子系统调用享元Flyweight共享细粒度对象节省内存对象池 内外部状态分离代理Proxy控制对象访问代理类持有真实对象引用共性通过组合而非继承实现结构的灵活扩展。3行为型模式11种核心关注点对象之间的职责分配、算法封装与通信方式。模式一句话说明关键拓扑特征责任链Chain of Responsibility请求沿链条传递直到被处理链表结构 处理器链命令Command将请求封装为对象命令对象 调用者与接收者解耦解释器Interpreter定义语法规则并解释执行抽象语法树 递归解释迭代器Iterator顺序访问聚合对象内部元素迭代器接口 聚合接口中介者Mediator对象间通过中介者通信而非直接引用星型拓扑中介者为中心备忘录Memento保存和恢复对象状态发起人 备忘录 caretaker观察者Observer状态变化时自动通知依赖者发布-订阅结构状态State状态变化时改变对象行为状态对象 上下文持有当前状态策略Strategy封装可互换的算法族策略接口 上下文持有策略引用模板方法Template Method定义算法骨架子类实现具体步骤继承 钩子方法访问者Visitor在不改变元素类的前提下定义新操作双分派 访问者与元素双向依赖共性将行为变化封装起来实现算法的可替换和职责的灵活分配。四、什么时候使用设计模式使用设计模式需要克制而非滥用。以下是指南4.1 适用场景的判断标准判断依据说明是否出现频繁变化某类需求经常变动需要隔离变化点是否存在重复代码相似逻辑出现在多个地方需要抽象耦合度是否过高修改一个类导致多个类需要改动扩展性是否需要提升未来可能需要增加新功能希望不修改现有代码复杂度是否需要管理单个类承担了过多职责需要拆分4.2 不同场景下看哪个类别遇到的问题优先查看的模式类别对象创建过程复杂、希望统一创建方式创建型模式类与类之间接口不匹配、需要适配结构型模式对象数量庞大、需要节省内存结构型模式享元对象行为随状态/策略变化行为型模式状态/策略对象之间需要解耦通信行为型模式观察者/中介者请求需要按顺序被多个处理器处理行为型模式责任链需要记录操作历史以支持撤销行为型模式命令/备忘录4.3 设计模式不是银弹不要使用设计模式的场景功能简单、不会变化 —— 引入模式反而增加复杂度团队对模式不熟悉 —— 模式带来的沟通成本可能大于收益性能敏感的核心路径 —— 某些模式如装饰器、代理可能引入额外开销原则先写简单直接的代码当变化和复杂度真正出现时再用设计模式重构。五、系列文章结构预告本系列将按以下顺序展开总纲本篇—— 全景式认知框架创建型模式5篇每篇一个模式结构型模式7篇行为型模式11篇总结——模式之间的关系、如何组合使用、反模式警示每篇具体模式文章将遵循统一结构问题场景什么时候用拓扑结构图类图/对象图核心代码骨架与其他模式的对比实际案例总结速查表类别数量核心问题一句话特征创建型5对象怎么创建将创建与使用分离结构型7对象怎么组合通过组合形成更大结构行为型11对象怎么通信封装行为与交互逻辑最终目的理解这些类的拓扑结构之后你不再需要死记硬背23个模式的名字而是能够在遇到问题时自然地想到——“这里应该用某种创建型模式来隔离变化”或者“这里需要某个结构型模式来适配接口”。
设计模式（类的拓扑结构）（描述总纲）
设计模式类的拓扑结构描述总纲写这系列的文章就两个目的了解什么是设计模式有哪几种理解什么时候使用这些设计模式结构这里系统的讲一下设计模式围绕下面几个核心的问题1.什么是设计模式2.为什么会有设计模式3.有哪些设计模式4.什么时候可以去使用设计模式具体设计模式类型1创建型模式5种核心解决对象创建过程的灵活性与耦合问题。单例Singleton工厂方法Factory Method抽象工厂Abstract Factory建造者Builder原型Prototype2结构型模式7种核心通过组合类或对象形成更大的结构。适配器Adapter桥接Bridge组合Composite装饰器Decorator外观Facade享元Flyweight代理Proxy3行为型模式11种核心处理算法与对象间职责的分配、通信。责任链Chain of Responsibility命令Command解释器Interpreter迭代器Iterator中介者Mediator备忘录Memento观察者Observer状态State策略Strategy模板方法Template Method访问者Visitor设计模式类的拓扑结构—— 描述总纲写作目的本系列文章围绕两个核心目标展开了解什么是设计模式以及有哪些设计模式理解在什么场景下可以使用这些设计模式结构核心问题本系列将系统性地回答以下四个问题问题简述什么是设计模式定义、本质、价值为什么会有设计模式产生背景、解决什么痛点有哪些设计模式三类23种模式的全景图什么时候用每种模式的适用场景与问题特征一、什么是设计模式设计模式是对软件开发中特定场景下重复出现的类与对象拓扑结构的总结与抽象。通俗地说设计模式就是一套被验证过的、可复用的设计经验。它不是可以直接落地的代码库而是一种解法模板——描述了在什么情况下类和对象应该如何组织、如何交互、如何承接职责从而形成一个可复用的、优雅的结构。从类的拓扑结构这个视角看设计模式本质上是在回答三个问题类与类之间如何连接继承、组合、依赖对象之间如何通信调用、通知、回调职责如何在对象之间分配谁做什么、谁不做什么一句话定义设计模式 特定问题场景下 经过验证的 类/对象拓扑结构二、为什么会有设计模式设计模式的产生源于软件开发中的重复性痛点2.1 核心痛点痛点表现紧耦合修改一处代码牵连一片重复造轮子类似的问题类似的解法每次都重新设计可维护性差代码难以理解、难以扩展、难以测试变动应对能力弱需求一变化架构就崩塌2.2 设计模式解决的三个根本问题封装变化—— 找到代码中可能变化的部分将其隔离面向接口/抽象编程而非实现—— 依赖抽象而非具体类组合优先于继承—— 运行时动态组合行为而非静态绑定2.3 历史背景1994年GoF四人组出版《设计模式可复用面向对象软件的基础》借鉴了建筑学中 Christopher Alexander 的“模式语言”思想总结了23种面向对象设计模式成为软件开发领域的经典三、有哪些设计模式GoF 将23种设计模式分为三大类1创建型模式5种核心关注点对象的创建过程。模式一句话说明关键拓扑特征单例Singleton一个类只有一个实例类持有自己的静态实例工厂方法Factory Method子类决定实例化哪个类继承 多态抽象工厂Abstract Factory创建一系列相关对象多个工厂接口 产品族建造者Builder分步构建复杂对象导向器 建造器分离原型Prototype通过拷贝原型创建对象克隆方法 原型注册表共性将“创建什么对象”与“如何使用对象”解耦。2结构型模式7种核心关注点类与对象的组合方式形成更大的结构。模式一句话说明关键拓扑特征适配器Adapter转换接口让不兼容的类协同工作包装器 接口转换桥接Bridge将抽象部分与实现部分分离抽象类持有实现类引用组合Composite统一对待单个对象和组合对象树形结构 统一接口装饰器Decorator动态添加职责包装器链 透明接口外观Facade为子系统提供统一入口门面类 子系统调用享元Flyweight共享细粒度对象节省内存对象池 内外部状态分离代理Proxy控制对象访问代理类持有真实对象引用共性通过组合而非继承实现结构的灵活扩展。3行为型模式11种核心关注点对象之间的职责分配、算法封装与通信方式。模式一句话说明关键拓扑特征责任链Chain of Responsibility请求沿链条传递直到被处理链表结构 处理器链命令Command将请求封装为对象命令对象 调用者与接收者解耦解释器Interpreter定义语法规则并解释执行抽象语法树 递归解释迭代器Iterator顺序访问聚合对象内部元素迭代器接口 聚合接口中介者Mediator对象间通过中介者通信而非直接引用星型拓扑中介者为中心备忘录Memento保存和恢复对象状态发起人 备忘录 caretaker观察者Observer状态变化时自动通知依赖者发布-订阅结构状态State状态变化时改变对象行为状态对象 上下文持有当前状态策略Strategy封装可互换的算法族策略接口 上下文持有策略引用模板方法Template Method定义算法骨架子类实现具体步骤继承 钩子方法访问者Visitor在不改变元素类的前提下定义新操作双分派 访问者与元素双向依赖共性将行为变化封装起来实现算法的可替换和职责的灵活分配。四、什么时候使用设计模式使用设计模式需要克制而非滥用。以下是指南4.1 适用场景的判断标准判断依据说明是否出现频繁变化某类需求经常变动需要隔离变化点是否存在重复代码相似逻辑出现在多个地方需要抽象耦合度是否过高修改一个类导致多个类需要改动扩展性是否需要提升未来可能需要增加新功能希望不修改现有代码复杂度是否需要管理单个类承担了过多职责需要拆分4.2 不同场景下看哪个类别遇到的问题优先查看的模式类别对象创建过程复杂、希望统一创建方式创建型模式类与类之间接口不匹配、需要适配结构型模式对象数量庞大、需要节省内存结构型模式享元对象行为随状态/策略变化行为型模式状态/策略对象之间需要解耦通信行为型模式观察者/中介者请求需要按顺序被多个处理器处理行为型模式责任链需要记录操作历史以支持撤销行为型模式命令/备忘录4.3 设计模式不是银弹不要使用设计模式的场景功能简单、不会变化 —— 引入模式反而增加复杂度团队对模式不熟悉 —— 模式带来的沟通成本可能大于收益性能敏感的核心路径 —— 某些模式如装饰器、代理可能引入额外开销原则先写简单直接的代码当变化和复杂度真正出现时再用设计模式重构。五、系列文章结构预告本系列将按以下顺序展开总纲本篇—— 全景式认知框架创建型模式5篇每篇一个模式结构型模式7篇行为型模式11篇总结——模式之间的关系、如何组合使用、反模式警示每篇具体模式文章将遵循统一结构问题场景什么时候用拓扑结构图类图/对象图核心代码骨架与其他模式的对比实际案例总结速查表类别数量核心问题一句话特征创建型5对象怎么创建将创建与使用分离结构型7对象怎么组合通过组合形成更大结构行为型11对象怎么通信封装行为与交互逻辑最终目的理解这些类的拓扑结构之后你不再需要死记硬背23个模式的名字而是能够在遇到问题时自然地想到——“这里应该用某种创建型模式来隔离变化”或者“这里需要某个结构型模式来适配接口”。
