导图社区 GOF的23种设计模式详细图1
GOF的23种设计模式是软件开发的经典解决方案,是每个开发者必备的设计工具。在AI火爆的今天,思维、解决方案就显得更加重要了。该思维导图从概要入手,介绍了设计模式的概念、分类、优点以及基本要.创建型模式部分,涵盖了单例模式、原型模式、工厂方法模式等5种模式,详细说明了每种模式的定义以及如何创建对象。这对于在软件设计中合理创建对象,提高代码的灵活性和可复用性具有重要意义,尤其适合需要优化代码结构的开发者。结构型模式包含代理模式、适配器模式、桥接模式等7种模式,阐述了如何组合类和对象以获得更大的结构,以及类与类之间的关系。它有助于设计出更稳定、更易于扩展的系统架构,是系统架构师和资深软件工程师的必备知识。行为型模式有模板方法模式、策略模式、命令模式等11种模式,描述了程序在运行时复杂的流程控制和对象之间的交互分配。这对于解决复杂的业务逻辑问题,使代码更易于理解和维护至关重要,适用于处理复杂业务场景的开发者。这份思维导图适用人群广泛,包括初入行的程序员,他们可以通过此模板快速入门设计模式;软件工程师能够借助它深化对设计模式的理解和应用;计算机科学专业的学生则可将其作为学习的重要参考资料。
编辑于2026-03-17 11:58:46该模板以经典的SWOT分析框架为基础,从优势、劣势、机会和威胁四个维度,剖析电商业务。在优势方面,涵盖了用户规模护城河、低价供应链、流量分发等关键要素。对于成熟的电商平台,庞大的用户群体是核心竞争力之一,能够形成强大的网络效应;低价供应链则有助于在价格竞争中占据主动;有效的流量分发机制可以提升平台的运营效率和用户体验。劣势部分指出了品牌信任挑战、客单价偏低、物流体验依赖第三方等问题。在电商市场竞争激烈的环境下,建立和维护品牌信任至关重要;客单价偏低可能影响平台的盈利能力;物流体验作为电商交易的重要环节。机会方面,下沉市场消费升级、农业赛道深耕、跨境电商新蓝海等为电商发展提供了新的增长点。随着下沉市场消费者购买力的提升,针对这一市场的精准营销和产品供应将成为新的机遇;农业电商的发展潜力巨大;跨境电商则受益于全球贸易的发展和消费者对海外商品的需求。威胁因素包括电商巨头围剿、流量红利见顶、政策与舆论风险等。这张电商SWOT分析模版图是电商行业从业者进行战略分析和业务规划的实用利器。无论你是电商企业的管理者、运营人员,还是准备投身电商领域的创业者,都能从中获得参考。
这张电商SWOT分析模板图是电商领域从业者不可或缺的战略分析工具,尤其适合电商企业管理人员、运营策划人员以及电商创业者使用。它以直观且系统的SWOT分析模型,全面梳理电商业务在内部和外部环境下的优势、劣势、机会与威胁,为电商业务的决策制定和战略规划提供清晰指引。在内部因素分析中,该模板详细拆解了电商业务的核心要素。优势方面,涵盖用户规模护城河、低价供应链以及流量分发机制等关键点。庞大的用户规模意味着更高的品牌知名度和市场影响力;低价供应链能保障产品的价格竞争力;有效的流量分发机制则有助于提升用户转化率和店铺运营效率。劣势部分则指出品牌信任挑战、客单价偏低以及物流体验依赖第三方等问题,这些因素可能制约电商业务的进一步发展。外部因素分析同样全面。机会方面,下沉市场消费升级为电商带来新的用户群体和消费需求;农业赛道深耕和跨境电商新蓝海则开辟了全新的业务增长点。然而,电商也面临着诸多威胁,如电商巨头围剿带来的竞争压力、流量红利见顶导致的获客成本增加,以及政策与舆论风险带来的不确定性。通过这个模板,电商从业者可以清晰地看到自身业务的全貌,明确自身的核心竞争力所在,同时识别出潜在的风险和挑战。
GOF的23种设计模式是软件开发的经典解决方案,是每个开发者必备的设计工具。在AI火爆的今天,思维、解决方案就显得更加重要了。该思维导图从概要入手,介绍了设计模式的概念、分类、优点以及基本要.创建型模式部分,涵盖了单例模式、原型模式、工厂方法模式等5种模式,详细说明了每种模式的定义以及如何创建对象。这对于在软件设计中合理创建对象,提高代码的灵活性和可复用性具有重要意义,尤其适合需要优化代码结构的开发者。结构型模式包含代理模式、适配器模式、桥接模式等7种模式,阐述了如何组合类和对象以获得更大的结构,以及类与类之间的关系。它有助于设计出更稳定、更易于扩展的系统架构,是系统架构师和资深软件工程师的必备知识。行为型模式有模板方法模式、策略模式、命令模式等11种模式,描述了程序在运行时复杂的流程控制和对象之间的交互分配。这对于解决复杂的业务逻辑问题,使代码更易于理解和维护至关重要,适用于处理复杂业务场景的开发者。这份思维导图适用人群广泛,包括初入行的程序员,他们可以通过此模板快速入门设计模式;软件工程师能够借助它深化对设计模式的理解和应用;计算机科学专业的学生则可将其作为学习的重要参考资料。
社区模板帮助中心,点此进入>>
该模板以经典的SWOT分析框架为基础,从优势、劣势、机会和威胁四个维度,剖析电商业务。在优势方面,涵盖了用户规模护城河、低价供应链、流量分发等关键要素。对于成熟的电商平台,庞大的用户群体是核心竞争力之一,能够形成强大的网络效应;低价供应链则有助于在价格竞争中占据主动;有效的流量分发机制可以提升平台的运营效率和用户体验。劣势部分指出了品牌信任挑战、客单价偏低、物流体验依赖第三方等问题。在电商市场竞争激烈的环境下,建立和维护品牌信任至关重要;客单价偏低可能影响平台的盈利能力;物流体验作为电商交易的重要环节。机会方面,下沉市场消费升级、农业赛道深耕、跨境电商新蓝海等为电商发展提供了新的增长点。随着下沉市场消费者购买力的提升,针对这一市场的精准营销和产品供应将成为新的机遇;农业电商的发展潜力巨大;跨境电商则受益于全球贸易的发展和消费者对海外商品的需求。威胁因素包括电商巨头围剿、流量红利见顶、政策与舆论风险等。这张电商SWOT分析模版图是电商行业从业者进行战略分析和业务规划的实用利器。无论你是电商企业的管理者、运营人员,还是准备投身电商领域的创业者,都能从中获得参考。
这张电商SWOT分析模板图是电商领域从业者不可或缺的战略分析工具,尤其适合电商企业管理人员、运营策划人员以及电商创业者使用。它以直观且系统的SWOT分析模型,全面梳理电商业务在内部和外部环境下的优势、劣势、机会与威胁,为电商业务的决策制定和战略规划提供清晰指引。在内部因素分析中,该模板详细拆解了电商业务的核心要素。优势方面,涵盖用户规模护城河、低价供应链以及流量分发机制等关键点。庞大的用户规模意味着更高的品牌知名度和市场影响力;低价供应链能保障产品的价格竞争力;有效的流量分发机制则有助于提升用户转化率和店铺运营效率。劣势部分则指出品牌信任挑战、客单价偏低以及物流体验依赖第三方等问题,这些因素可能制约电商业务的进一步发展。外部因素分析同样全面。机会方面,下沉市场消费升级为电商带来新的用户群体和消费需求;农业赛道深耕和跨境电商新蓝海则开辟了全新的业务增长点。然而,电商也面临着诸多威胁,如电商巨头围剿带来的竞争压力、流量红利见顶导致的获客成本增加,以及政策与舆论风险带来的不确定性。通过这个模板,电商从业者可以清晰地看到自身业务的全貌,明确自身的核心竞争力所在,同时识别出潜在的风险和挑战。
GOF的23种设计模式是软件开发的经典解决方案,是每个开发者必备的设计工具。在AI火爆的今天,思维、解决方案就显得更加重要了。该思维导图从概要入手,介绍了设计模式的概念、分类、优点以及基本要.创建型模式部分,涵盖了单例模式、原型模式、工厂方法模式等5种模式,详细说明了每种模式的定义以及如何创建对象。这对于在软件设计中合理创建对象,提高代码的灵活性和可复用性具有重要意义,尤其适合需要优化代码结构的开发者。结构型模式包含代理模式、适配器模式、桥接模式等7种模式,阐述了如何组合类和对象以获得更大的结构,以及类与类之间的关系。它有助于设计出更稳定、更易于扩展的系统架构,是系统架构师和资深软件工程师的必备知识。行为型模式有模板方法模式、策略模式、命令模式等11种模式,描述了程序在运行时复杂的流程控制和对象之间的交互分配。这对于解决复杂的业务逻辑问题,使代码更易于理解和维护至关重要,适用于处理复杂业务场景的开发者。这份思维导图适用人群广泛,包括初入行的程序员,他们可以通过此模板快速入门设计模式;软件工程师能够借助它深化对设计模式的理解和应用;计算机科学专业的学生则可将其作为学习的重要参考资料。
GOF的23种设计模式
概要
概念
解决特定问题的一些列套路,只能解决一类特定的问题,不是万能的
其本质是对面向对象设计原则的实际运用。是对类和封装性、继承性和多态性以及类的关联关系和组合关系的充分理解
分类
优点
提高思维能力、编程能力、设计能力
使程序设计更加标准化、代码编制更加工程化、提高软件开发效率,缩短开发周期
提高代码的可重用性、可读性、可靠性、可维护性
基本要素
模式名称
问题
解决方案
效果
创建型模式(5)
单例模式【Singleton】
定义:保证一个类仅有一个实例【类自身保存唯一实例】,并提供一个可访问它的全局访问点【全局访问,实例化控制】
结构图
核心
1、私有化构造函数,对外暴露访问对象的静态接口
2、单例对象为静态变量
多线程时的单例
饿汉
静态初始化
被加载时初始化
类为sealed类,防止被继承
单例对象为静态只读
懒汉
双重IF + 锁定
锁对象为静态只读对象
被引用时初始化
好处
保证唯一实例
对唯一实例的受控访问【怎么访问,何时访问】
节约系统资源
缺点
常驻内存,不会被释放
当在一处进行对象的修改,所有使用改对象的地方都会进行修改【用的是同一个对象】
应用场景
资源共享的情况下,避免由于资源操作时导致的性能或损耗
eg:数据库连接池,应用程序的日志应用等
控制资源的情况下,方便资源之间的互相通信
eg:线程池
原型模式【Prototype】
定义:用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象【原型克隆自身来创建可制定的新的对象】
结构图
核心
克隆
拷贝
对于值类型,深拷贝和浅拷贝的效果是一样的,主要区别在于引用类型:是否获取到了一个对象的真正对象实体,而不是引用【引用类型中的变量是否有被拷贝】
深拷贝
增加了一个指针并且申请了一个新的内存,使这个增加的指针指向这个新的内存【修改原型对象中引用类型的值不会改变副本中和原型中对应引用类型的值】【序列化来进行深克隆】
Serialize
浅拷贝
只是增加了一个指针指向已存在的内存地址【修改原型对象中引用类型的值会引起副本中和原型中对应引用类型的值的改变】
好处
提高性能【克隆比new 快】
隐藏对象创建细节
实现克隆操作
C#
继承接口ICloneable,重写Clone方法或是直接写个Clone函数里面调用MemberwiseClone() 方法进行 对象拷贝
关于MemberwiseClone()【浅拷贝】
值类型
复制值
引用类型
复制引用
应用场景
对象之间相同或相似,即只是个别的几个属性不同的时候
对象的创建过程比较麻烦
类初始化需要消化非常多的资源
需要非常繁琐的数据准备或访问权限
一个对象需要提供给其他对象访问,而且各个调用者可能需要修改其值,可以考虑使用原型模式拷贝多个对象供调用者使用,即保护性拷贝
按需更新数据库,值更新修改了的(写sql的时候),克隆一分原来的数据,然后把修改后和原来的做比较
数据回滚
工厂方法模式【FactoryMethod】
定义:定义一个用于创建对象的接口,让子类决定实例化哪一类。工厂方法使一个类的实例化延迟到其子类
结构图
核心
每一个对象的的创建都用一个工厂类来出来
工厂一个抽象,产品一个抽象
优点
不修改具体工厂角色的情况下引进新产品【满足开闭原则】
封装了对象的创建过程
对扩展开放,对修改封闭
缺点
为每一个对象的创建都增加了一个工厂类,增加了代码量
考虑的是一类产品的生产
应用场景
日志记录器
多种数据库访问
抽象工厂模式【AbstractFactory】
定义:提供一个创建一系列相关或是相互依赖对象的接口,而无需指定它们具体的类
结构图
核心
一个抽象的工厂(定义好工厂职责),该工厂里有一个产品簇对象的创建
和工厂模式结构差不多,唯一的区别是,工厂里面不再是负责一个对象的创建,而是一个产品簇的所有对象的创建
优点
便于交换产品系列
具体的创建实例过程和客户端分离
倾斜的可扩展设计
对产品簇的增加可扩展
工厂职责不可扩展
缺点
代码量多
对产品簇内部结构的扩展很困难
在一个工厂里聚合多个同类产品
应用场景
访问不同数据库
QQ换肤
生成不同操作系统的程序
需要创建一组对象,该组对象有不同的版本【工厂职责不稳定的情况下不适合使用该模式】
建造者模式【Builder】
定义:将一个复杂对象的构建和它的表示分离,使得同样的构建过程可以创建不同的表示
结构图
核心
主要有四个角色
产品
目标产品
具体建造者
抽象建造者内部接口的具体实现
抽象建造者
提供创建目标产品的各个部件的抽象接口和一个获取目标产品的接口
指挥官
管理建造出来的实例的依赖关系
构建目标产品的流程的控制(避免出现在构建环节出现部件构建遗漏的问题)
处理的是【建造流程】,而不是具体的对象的创建,具体的对象创建是在具体建造者里面进行的
优点
各个具体的建造者相互独立,有利于系统的扩展
客户端不必知道产品内部组成的细节,便于控制细节风险。
可以更加精细地控制产品的创建过程
缺点
建造者模式所创建的产品一般具有较多的共同点,其组成部分相似,如果产品之间的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制
如果产品的内部变化复杂,可能会导致需要定义很多具体建造者类来实现这种变化,导致系统变得很庞大
应用场景
对象内部结构间的构建顺序是稳定的,但是内部构建是复杂变化的
需要生成的产品对象有复杂的内部结构,这些产品对象通常包含多个成员属性
相同的方法,不同的执行顺序,产生不同的事件结果时
对象的创建过程独立于创建该对象的类
扩展
变种的 Builder 模式
解决的问题:
当类的构造函数的参数太多,超过4个,并且有些参数可选
只有一个构建者,构建者设置属性值,返回是当前对象。这样可以通过链式调用的方式进行给对象的参数赋值
如何创建对象
结构型模式(7)
代理模式【Proxy】
定义:为其他对象提供一种代理以控制对这个对象的访问
结构图
核心
在目标类和调用端中间加一层(代理层),在代理成里面维护一个目标类的对象,在不修改目标类的前提下增加额外扩展功能
不要在代理类里面增加业务逻辑
优点
代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用
代理对象可以扩展目标对象的功能
代理模式能将客户端与目标对象分离,在一定程度上降低了系统的耦合度
缺点
一个服务就需要增加一个代理
应用场景
远程代理
虚拟代理
安全代理
智能指引
延迟加载
AOP:日志代理 延迟代理 权限代理 单例代理 缓存代理
现有应用
WCF / webservice /ORM
适配器模式【Adapter】
定义:将一个类的接口转换成客户希望的另一个接口【该模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作】
结构图
核心
类适配器
用一个中间类继承本地统一的接口,和第三方的类
继承是强耦合,子类必须继承父类的所有公开成员
对象适配器
用一个中间类继承本地统一的接口,在中件类中维护一个第三方类的对象
子类想要什么是由自己控制的,较类适配器更为灵活
组合优于继承
优点
客户端通过适配器可以透明地调用目标接口
复用现存的类
将目标类和适配者类解耦
灵活性好
应用场景
使用第三方提供的组件
两个类所做的事相同或是相似,但是接口不一样
对现有的东西进行一个改造
不在项目最初使用改模式,项目已经稳定了,需要改造或是集成一些新的功能
桥接模式【Bridge】
定义:将抽象部分和它的实现部分分离,使它们都可以独立的变化
结构图
核心
将可变的部分进行抽象封装
优点
扩展能力强
实现细节透明
抽象和实现的分离
减少子类个数:由M*N*……变为M+N+……
缺点
上端需要了解更多的细节
应用场景
当一个类存在两个独立变化的维度,且这两个维度都需要进行扩展时
当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时
当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时
解决多维度的变化
装饰模式【Decorator】
定义:动态地给一个对象添加一些额外的职责【就增加功能来讲,该模式比生成子类更加灵活】
结构图
核心
装饰对象和被装饰的对象够够必须继承同一个基类,在装饰类中维护一个局部变量(基类)
优点
灵活
类的装饰功能从类中移除,简化原有的类
核心职责和装饰功能分开,去除了相关类中重复的装饰逻辑
应用场景
扩展一个类的功能
动态增加功能,动态撤销
有叫包装器模式
外观模式【Facade】
定义:为子系统中的一组接口提供一个一致的界面,该模式定义了一个高层接口,这个接口使得这一子系统更加容易使用
结构图
核心
将业务逻辑转一个到外观类中,上端通过外观类和业务逻辑交互
就是业务逻辑向上封住一层,简化客户端的使用
优点
减少系统相互依赖
提高灵活性
降低了大型软件系统中的编译依赖性,简化了系统在不同平台之间的移植过程
应用场景
对分层结构系统构建时
当一个复杂系统的子系统很多时
当客户端与多个子系统之间存在很大的联系时
知识点
外观模式和三层架构中的BLL的区别,BLL是外观模式的一种体现
门面模式通产是单例的,
门面内部是不允许越过系统去做本该由系统来完成的业务逻辑
享元模式【Flyweight】
定义:运用共享技术有效地支持大量细粒度的对象
结构图
状态
内部状态
不会随着环境的改变而改变的可共享部分
外部状态
指随环境改变而改变的不可以共享的部分
核心
由一个享元工厂,对共享资源对象进行统一的控制,实例化一次共享资源,并进行共享资源的缓存,其他访问共享资源的时候就不需要再次实例化共享资源对象了,直接从缓存中获取
好处
大大减少对象的创建,降低系统的内存,使效率提高
应用场景
系统有大量相似对象
需要缓冲池的场景
现有应用
线程池
线程池详解
数据库连接池
字符串
单例和享元的对比
单例在整个进程中对象只有一个实例,只能实例化一次,外面不能再实例化了,实例的对象是由自身控制的,构造函数私有化
享元工厂控制通过工厂获取的对象在整个进程中只有一个实例,但是实例对象不是强制有享元工厂控制的,(可以由工厂提供,也可以自行单独创建)对象的构造函数不是私有化的
不是所有的类都可以做成单例,但是所有的类都可以使用享元工厂
享元,加入一个第三方工厂 控制对象的创建,实现对象的单例访问
组合模式【Composite】
定义:讲对象组合成树形结构以表示"部分-整体"的层次结构,【该模式使得用户对单个对象和组合对象的使用具有一致性】
结构图
核心
用递归的方式去处理树结构的数据集合
优点
高层模块调用简单
节点自由增加
应用场景
在需要表示一个对象整体与部分的层次结构的场合
要求对用户隐藏组合对象与单个对象的不同,用户可以用统一的接口使用组合结构中的所有对象的场合
知识点
递归
原理:自己调用自己
注意事项: 一定要有跳出条件
缺点:很是消耗资源
使用场景:不限数量级 不限深度的访问(树形结构的访问)
树形结构
菜单
文件夹
人事架构
组合模式区别
安全模式
整体类和叶子类的结构不一样,整体类需要增加AddChild函数,叶子类就不需要有改函数
透明模式
叶子类和整体类结构一样,两则都有AddChild函数
有叫部分-整体模式
如何组合类和对象以获得更大的结构【类与类之间的关系(继承/组合)】
类结构模型
采用继承机制来组织接口和类
对象结构模式
采用组合或聚合来组合对象
对象结构模式灵活性更大
行为型模式(11)
模板方法模式【TemplateMethod】
定义:定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。该模板使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤【父类定义好通用的框架、流程,子类负责个性的不同步骤的实现】
结构图
核心:抽象类的运用
优点
封装了不变部分,扩展可变部分,扩展性好
在父类中提取了公共的部分代码,便于代码复用
部分方法是由子类实现的,因此子类可以通过扩展方式增加相应的功能,符合开闭原则
可以使用钩子方法,增加了系统的灵活性
缺点
每种不同的实现都会增加一个子类,子类较多
具体实现在子类中,反向控制,增加了阅读难度
应用场景
一个系统时知道了算法所需的关键步骤,而且确定了这些步骤的执行顺序,但某些步骤的具体实现还未知,或者说某些步骤的实现与具体的环境相关【逻辑相同,具体实现不同】
当不变和可变的行为在子类的方法实现中混合在一起的时候,不变的行为会在子类中重复出现
补充
生词
ConCreteClass:具体类
AbstractClass:抽象类
知识点
new
隐藏父类的方法,调用父类被隐藏的函数用 base.方法名
virtual-override
子类可以重写父类的虚方法
abstract-override
子类必须实现父类的抽象方法(父类的抽象方法是没有方法体的)
父类的override方法子类可以继续override【重写的是父类的父类的非普通方法】,如果不重写,具调父类的override方法
注意点
方法体的长度不要太长,不要超过30行
接口为了描述它可以做什么,偏功能、抽象类为了描述它是什么,偏属性
现有运用
MVC的Controller
策略模式【Strategy】
定义:定义了算法家族,分别封装起来,让他们之间可以相互替换,该模式让算法的变化,不会影响到使用算法的客户
结构图
核心
抽象类的运用
在具体的子类调用之前再加一个上下文类,只将上下文类暴露给客户端,可以将客户端和业务逻辑都不关注但是又必须操作的业务,就可以交给上下文来操作【例如:写日志】
一般和简单工厂一起使用
优点
降低算法和使用算法之间的耦合
避免使用多重条件语句
简化单元测试
避免代码重复
灵活增加新算法,扩展性良好
缺点
策略模式会有很多策略子类
策略模式只适用于客户端知道所有的算法或行为的情况
应用场景
系统需要动态地在几种算法中选择一种时
一个类定义了多种行为,并且这些行为在这个类的操作中以多个条件语句的形式出现
系统中各算法彼此完全独立,且要求对客户隐藏具体算法的实现细节时
系统要求使用算法的客户不应该知道其操作的数据时
多个类只区别在表现行为不同
知识点
暴露给客户端的类越少越好
不同的行为堆砌在一个类时,很难避免使用条件语句来选择合适的行为。如果将不同的行为封装在一个个独立的策略中,就可以在使用这里行为的类中消除条件语句
命令模式【Command】
定义:将一个请求封装成一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或是记录请求日志,以及支持可撤销的操作
结构图
核心
将对象行为的调用封装成单独的类
将命令和命令执行者分开
命令执行者可以进行扩展
命令的调用也可以进行扩展(配置+反射)
抽象命令-具体命令-调用者-执行者
优点
容易设计一个命令队列
容易将命令计入日志
允许接收请求的一方决定是否要否定请求
增减命令方便 扩展比较灵活
降低系统的耦合度
缺点
导致具体的命令类过多
应用场景
系统需要将请求调用者与请求接收者解耦
系统需要支持命令的撤销
需要在不同的时间制定请求、将请求排队
要将系统中所有的数据更新到日志里
知识点
注入一个对象的两种方式
直接传参数
set;get 方法
在系统架构,程序架构上价值更大
保存数据时,把命令语句进行日志保存【可以方便以后数据丢失时的数据恢复】
现有运用
12306下单买票排队
数据恢复、命令撤销
责任链模式【ChainofResponsibility】
定义:使多个对象都有机会处理请求,从而避免请求的发送者和接受者质检的耦合关系,将这个对象连成一条链,并沿着这条链传递请求,直到有一个对象处理它为止。
结构图
核心
每个节点的下一级处理对象通过动态的方式进行设置,在父类中维护一个下级对象
抽象类的继承
处理多步骤的问题
将一个复杂的流程分成多个步骤来处理
优点
降低了对象之间的耦合度
增强了系统的可扩展性
增强了给对象指派职责的灵活性
责任链简化了对象之间的连接
职责分担
缺点
具体的处理类很多
应用场景
有多个对象可以处理同一个请求,具体哪个对象处理该请求由运行时刻自动确定
可动态指定一组对象处理请求,或添加新的处理者
在不明确指定请求处理者的情况下,向多个处理者中的一个提交请求
一个业务有多个处理环节,每个环节处理相似
分类
纯粹
在过程中只有处理和不处理两种结果
必须有一个最终的处理结果
不纯粹【应用更过】
在处理的过程中只做部分的处理(不管处理还是不处理,都会处理这个部分的内容)
现有应用
http请求中的25个事件
电商的优惠政策
工作流
知识点
责任链的长度不应过长
状态模式【State】
定义:当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类【当一个对象状态转变的条件表达过于复杂时,把状态的判断逻辑转移到表示不同状态的一系列类中】
结构图
核心
抽象类的运用
在上下文中保留当前状态
对客户端只暴露一个类(上下文类)
调用的同样的函数,但是运行的结构却有不同。
优点
将与特定状态相关的行为局部化到一个状态中,并且将不同状态的行为分割开来
减少对象间的相互依赖
有利于程序扩展
消除庞大的分支语句
缺点
类变多了,程序复杂了
应用场景
一个对象的行为取决于状态,并且在运行时时刻根据状态改变它的行为
有庞大的分支
实例:投票
观察者模式【Observer】
定义:定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时,会通知所有观察者对象,使它们能够自动更新自己
结构图
核心
在主题类中需要维护一个观察者的集合
主题类需要暴露观察者的增加、删除、通知接口
主题和观察者的关系:一对多
优点
降低了目标与观察者之间的耦合关系
建立一套触发机制
缺点
观察者必须具有一致性
如果一个被观察者对象有很多的直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间
如果在被观察者之间有循环依赖的话,被观察者会触发它们之间进行循环调用,导致系统崩溃。在使用观察者模式是要特别注意这一点
如果对观察者的通知是通过另外的线程进行异步投递的话,系统必须保证投递是以自恰的方式进行的
虽然观察者模式可以随时使观察者知道所观察的对象发生了变化,但是观察者模式没有相应的机制使观察者知道所观察的对象是怎么发生变化
应用场景
当一个对象的改变需要同时改变其他对象的时候
当一个抽象模型有两个方面,其中一个方面依赖于另一方面时,可将这二者封装在独立的对象中以使它们可以各自独立地改变和复用
中介者模式【Mediator】
定义:用一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显示地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互
又叫调停者模式
结构图
核心
在消息接收和消息发送者之间引入中间类,在中间维护一个同事集合类,消息发送者将消息发送给中间类,由中间类来负责需要通知需要接收消息的对象
优点
各个类之间的解耦
降低了类的复杂度,将一对多转化成了一对一,提高了灵活性,更易于维护和扩展
缺点
当同事类太多时,中介者的职责将很大,它会变得复杂而庞大,以至于系统难以维护
应用场景
当对象之间存在复杂的网状结构关系而导致依赖关系混乱且难以复用时
想通过一个中间类来封装多个类中的行为,而又不想生成太多的子类
对象交互
群发
现有运用
数据库设计中的中介者模式
用户-菜单
映射表、中间表,关联表(等同于中介者)
迭代器模式【Iterator】
定义:提供一种方法顺序访问一个聚合对象中各个元素,而又不是暴露改对象的内部表示
结构图
核心
具体聚集类中维护一个集合,同时向外暴露一个获取迭代器的接口
为每个具体的聚集类实现一个迭代器
每个具体的迭代器可以用.net 现有的迭代器接口IEnumberator来实现
优点
访问一个聚合对象的内容而无须暴露它的内部表示
遍历任务交由迭代器完成,这简化了聚合类
支持以不同方式遍历一个聚合,甚至可以自定义迭代器的子类以支持新的遍历
增加新的聚合类和迭代器类都很方便,无须修改原有代码
封装性良好,为遍历不同的聚合结构提供一个统一的接口
缺点
增加了类的个数,这在一定程度上增加了系统的复杂性
应用场景
当需要为聚合对象提供多种遍历方式时
当需要为遍历不同的聚合结构提供一个统一的接口时
当访问一个聚合对象的内容而无须暴露其内部细节的表示时
现有应用
foreach
类型包含 公开的 GetEnumerator方法
系统的提供的迭代器接口:IEnumerator
自定义的迭代器必须实现改接口,同时在类型里面向外暴露 获取迭代器的接口
知识点
Yield
状态机
延迟查询,按需获取
https://www.cnblogs.com/blueberryzzz/p/8678700.html
访问者模式【Visitor】
定义:表示一个作用于某对象结构中的各元素的操作,它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作
结构图
核心
目的是为了把处理从数据结构中分离出来
具体的处理实现在访问者里面实现,元素通过访问这来访问具体的函数
优点
增加新的操作容易,扩展性好
复用性好
灵活性好
符合单一职责原则
缺点
增加新的元素类很困难
破坏封装
应用场景
对象结构相对稳定,但其操作算法经常变化的程序【有比较稳定的数据结构,又有易于变化的算法】
对象结构中的对象需要提供多种不同且不相关的操作,而且要避免让这些操作的变化影响对象的结构
对象结构包含很多类型的对象,希望对这些对象实施一些依赖于其具体类型的操作
知识点
双分派技术
现有应用
消息处理
备忘录模式【Memento】
定义:在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态
结构图
核心
用一个单独类来保存需要备份的状态
在管理者里面存储备份信息
可以保存在内存中
可以保存在数据库
或是文本文档
在发起人里面向外暴露两个接口,一个备份,一个恢复
优点
提供了一种可以恢复状态的机制
实现了内部状态的封装
简化了发起人类
缺点
存在资源消耗大的问题
应用场景
需要保存与恢复数据的场景
需要提供一个可回滚操作的场景
做工具用的多
知识点
静态在内存中是唯一的,是不会丢失的
.net 提供的内存缓存(System.Runtime.Caching / MemoryCache与Microsoft.Extensions.Caching.Memory,)就是一个静态字典
shift+delete 删除一行
alt+鼠标左键 可以多行同时修改
现有应用
文件自动备份
解释器模式【Interpreter】
定义:定义一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子
结构图
优点
扩展性好
语法规则可以随意修改
随意定值自己的解释器
缺点
执行效率较低
会引起类膨胀,解释规则多(会为每一条规则定义一个类)-会导致子类增多
可应用的场景比较少
包含有无数的循环,性能会有所影响
应用场景
一个简单语法需要解释的场景
当一个语言需要解释执行,并且语言中的句子可以表示为一个抽象语法树的时候
一些重复出现的问题可以用一种简单的语言来进行表达
主要用途
做语法分析工具
运算表达式计算,正则表达式
机器人
现有使用
数据库关键字着色
模板引擎
网页静态化
描述程序在运行时复杂的流程控制,类和对象如果交付以及分配职责【对象和行为的分离】
类行为模式
采用继承机制在类间分派行为
对象行为模式
采用组合或是聚合在对象间分配行为
对象行为模式灵活性更大
按照目的进行划分
参考资料
大话设计模式(DPF电子书)
提取码:bueo
设计模式
深入浅出设计模式(电子书【部分】)
提取码:6bs8