admin管理员组文章数量:1032832
常用设计模式UML图示
1. 简介
设计模式是常见软件设计问题的可重用解决方案。它们提供了一种描述和记录软件架构的方法，以及开发人员交流软件设计的常用词汇。
一般设计模式按用途可以分成有3种类型，它们分别是创建模式、结构模式和行为模式。
创建模式处理对象创建机制，尝试以恰当的方式创建对象。
结构模式处理对象组合，处理对象之间创建关系以形成更大的结构。
行为模式侧重于对象之间的通信，对象之间发生的事情以及它们如何协同工作。
2. 创造模式
2.1 Singleton-单例
单一实例设计模式用于确保类只有一个实例，并为该实例提供全局访问点。
图 1：单例 UML。
- 使用单一实例设计模式的一个优点是，它确保一个类只有一个实例，这对于管理资源（如数据库连接或网络套接字）的类非常有用。
- 它还为实例提供了一个全局访问点，这样可以更轻松地在代码的不同部分中使用实例。
2.2 Factory-工厂
提供一种无需指定将创建的确切对象类即可创建对象的方法。具有创建特定类型的对象的方法。该方法将要创建的对象类型作为参数，并返回该类型的新对象。
图 2：工厂 UML。
- 使用工厂设计模式的一个优点是，它允许将对象的创建集中在单个位置，这可以使代码更加模块化且更易于维护。
- 它还允许轻松更改对象创建的实现，从而使设计更加灵活和可扩展。
- 允许在不指定其确切类的情况下创建对象，这可以使代码更加通用和可重用。
2.3 Abstract Factory-抽象工厂
提供一个接口，用于创建相关对象或从属对象的族，而无需指定其具体类。
图 3：抽象工厂 UML。
- 系统应该独立于其产品的创建、组成和表示方式。
- 系统应配置多个产品系列之一。
- 一系列相关产品对象设计为一起使用，您需要强制实施此约束。
- 当您想要创建与特定应用程序或框架兼容的对象，但不想在运行时之前指定对象的具体类时，这很有用。
2.4 Builder-建造者模式
允许逐步创建复杂对象。它将对象的构造与其表示分开，允许创建不同的表示。
图 4：生成器 UML。
- 对象创建算法应与系统分离。
- 需要创建算法的多种表示形式。
- 无需更改核心代码即可添加新的创建功能。
- 需要对创建过程进行运行时控制。
2.5 Prototype-原型
允许通过复制现有对象来创建新对象，而不是从头开始创建新对象。
图 5： 原型 UML。
- 在创建复杂对象或创建新对象的成本较高时很有用。
- 类将不知道需要创建哪些类。
- 子类可以指定应创建哪些对象。
- 父类希望将创建推迟到其子类。
3. 结构模式
3.1 Adapter-适配器
通过将适配器类包装在其中一个接口周围，允许两个不兼容的接口协同工作。此适配器类将适配类的接口转换为客户端所需的接口。
图 6： 适配器 UML。
- 适配器不仅可以将数据转换为各种格式，还可以帮助具有不同接口的对象进行协作。
- 可以创建一个双向适配器，可以在两个方向上转换呼叫。
3.2 Bridge-桥接
允许抽象和实现分离，以便两者可以独立变化。
图 7：桥接 UML。
- 抽象和实现不应在编译时绑定。
- 抽象和实现应该是可独立扩展的。
- 抽象实现中的更改不应对客户端产生影响。
- 实现详细信息应向客户端隐藏。
3.3 Bridge-复合
允许将对象视为单个单元。它用于将对象组合成树结构，并从简单的对象创建复杂的对象。
图 8： 复合 UML。
- 需要对象的分层表示形式。
- 应统一对待对象和对象的组合。
3.4 Decorator-装饰器
允许在不更改其结构的情况下向现有对象动态添加新行为。
图 9：装饰器 UML。
- 它可用于向类添加新功能或使用附加功能包装现有类。
3.5 Facade-门面模式
为复杂系统提供简化的界面。
图 10： 门面模式 UML。
- 当系统具有大量互连的类或客户端只需要访问有限数量的系统功能时，这很有用。
- 它将客户端与复杂的子系统分离，并允许更轻松地维护和修改系统。
3.6 Flyweight-享元模式
旨在通过在对象之间共享公共数据来最大程度地减少内存的使用。这是通过创建可由多个对象使用的共享对象来完成的，而不是每个对象都有自己单独的数据实例。
图 11： 享元模式 UML。
- 我们可以减少应用程序的内存占用并提高其性能。
- 仔细考虑节省内存的好处与实现模式增加的复杂性之间的权衡。
3.7 Proxy-代理
提供客户端和真实主体之间的中间对象。
代理模式可用于：
图 12： 代理 UML。
- 为可能昂贵或资源密集型的对象提供占位符。代理只能在需要时用于创建真实对象，而不是预先创建它。
- 控制对真实主题的访问。代理可用于强制实施访问限制或实施身份验证和授权检查。
- 为真实主题添加附加功能。代理可用于拦截对真实主体的请求，并在转发请求之前或之后执行其他任务。
4. 行为模式
4.1 Chain of Responsibility-责任链
允许对象向对象链发送请求以处理请求。
图 13：责任链 UML。
- 适用于多个对象可能能够处理一个请求的情况，并且事先不知道应处理请求的特定对象。
- 允许在不中断整体功能的情况下轻松地从链中添加或删除对象。
4.2 Command-命令
允许将请求封装为对象，然后可以将其传递给接收方执行。
图 14： 命令 UML。
- 允许将请求的发送方和接收方分开。
- 能够对请求进行排队或记录，并支持撤消/重做功能。
4.3 Iterator-迭代器
允许客户端按顺序访问聚合对象的元素，而无需公开对象的基础表示形式。
图 15： 迭代器 UML。
- 允许客户端以一致、统一的方式遍历对象集合，而不考虑集合的具体实现。
4.4 Mediator-调解员
允许多个对象相互通信，而无需知道其实现的详细信息。
图 16： 调解器 UML。
- 它提供了一个称为中介的中心通信点，它充当对象之间的中介。
- 在有大量对象需要相互通信的情况下很有用，因为它通过将通信逻辑与对象本身分开来降低系统的复杂性。
4.5 Observer-观察者
允许对象（主体）在其状态更改时通知一组对象（观察者）。观察者模式也称为发布-订阅模式。
图 17： 观察者 UML。
- 当您希望确保各种对象彼此保持同步时，或者当您希望能够彼此独立地重用主体和观察者时，非常有用。
4.6 Strategy-策略
允许对象通过切换到其他策略对象在运行时更改其行为或策略。
图 18： 策略 UML。
- 许多相关类之间的唯一区别是它们的行为。
- 需要算法的多个版本或变体。
- 算法访问或利用调用代码不应公开的数据。
- 类的行为应在运行时定义。
- 条件语句很复杂且难以维护。
4.7 Template Method-模板方法
定义算法的步骤，并允许子类重写某些步骤，同时仍保留算法的整体结构。
图 19： 模板方法 UML。
- 需要算法的单个抽象实现。
- 子类之间的常见行为应本地化为公共类。
- 父类应该能够统一调用其子类中的行为。
- 大多数或所有子类都需要实现该行为。
常用设计模式UML图示
1. 简介
设计模式是常见软件设计问题的可重用解决方案。它们提供了一种描述和记录软件架构的方法，以及开发人员交流软件设计的常用词汇。
一般设计模式按用途可以分成有3种类型，它们分别是创建模式、结构模式和行为模式。
创建模式处理对象创建机制，尝试以恰当的方式创建对象。
结构模式处理对象组合，处理对象之间创建关系以形成更大的结构。
行为模式侧重于对象之间的通信，对象之间发生的事情以及它们如何协同工作。
2. 创造模式
2.1 Singleton-单例
单一实例设计模式用于确保类只有一个实例，并为该实例提供全局访问点。
图 1：单例 UML。
- 使用单一实例设计模式的一个优点是，它确保一个类只有一个实例，这对于管理资源（如数据库连接或网络套接字）的类非常有用。
- 它还为实例提供了一个全局访问点，这样可以更轻松地在代码的不同部分中使用实例。
2.2 Factory-工厂
提供一种无需指定将创建的确切对象类即可创建对象的方法。具有创建特定类型的对象的方法。该方法将要创建的对象类型作为参数，并返回该类型的新对象。
图 2：工厂 UML。
- 使用工厂设计模式的一个优点是，它允许将对象的创建集中在单个位置，这可以使代码更加模块化且更易于维护。
- 它还允许轻松更改对象创建的实现，从而使设计更加灵活和可扩展。
- 允许在不指定其确切类的情况下创建对象，这可以使代码更加通用和可重用。
2.3 Abstract Factory-抽象工厂
提供一个接口，用于创建相关对象或从属对象的族，而无需指定其具体类。
图 3：抽象工厂 UML。
- 系统应该独立于其产品的创建、组成和表示方式。
- 系统应配置多个产品系列之一。
- 一系列相关产品对象设计为一起使用，您需要强制实施此约束。
- 当您想要创建与特定应用程序或框架兼容的对象，但不想在运行时之前指定对象的具体类时，这很有用。
2.4 Builder-建造者模式
允许逐步创建复杂对象。它将对象的构造与其表示分开，允许创建不同的表示。
图 4：生成器 UML。
- 对象创建算法应与系统分离。
- 需要创建算法的多种表示形式。
- 无需更改核心代码即可添加新的创建功能。
- 需要对创建过程进行运行时控制。
2.5 Prototype-原型
允许通过复制现有对象来创建新对象，而不是从头开始创建新对象。
图 5： 原型 UML。
- 在创建复杂对象或创建新对象的成本较高时很有用。
- 类将不知道需要创建哪些类。
- 子类可以指定应创建哪些对象。
- 父类希望将创建推迟到其子类。
3. 结构模式
3.1 Adapter-适配器
通过将适配器类包装在其中一个接口周围，允许两个不兼容的接口协同工作。此适配器类将适配类的接口转换为客户端所需的接口。
图 6： 适配器 UML。
- 适配器不仅可以将数据转换为各种格式，还可以帮助具有不同接口的对象进行协作。
- 可以创建一个双向适配器，可以在两个方向上转换呼叫。
3.2 Bridge-桥接
允许抽象和实现分离，以便两者可以独立变化。
图 7：桥接 UML。
- 抽象和实现不应在编译时绑定。
- 抽象和实现应该是可独立扩展的。
- 抽象实现中的更改不应对客户端产生影响。
- 实现详细信息应向客户端隐藏。
3.3 Bridge-复合
允许将对象视为单个单元。它用于将对象组合成树结构，并从简单的对象创建复杂的对象。
图 8： 复合 UML。
- 需要对象的分层表示形式。
- 应统一对待对象和对象的组合。
3.4 Decorator-装饰器
允许在不更改其结构的情况下向现有对象动态添加新行为。
图 9：装饰器 UML。
- 它可用于向类添加新功能或使用附加功能包装现有类。
3.5 Facade-门面模式
为复杂系统提供简化的界面。
图 10： 门面模式 UML。
- 当系统具有大量互连的类或客户端只需要访问有限数量的系统功能时，这很有用。
- 它将客户端与复杂的子系统分离，并允许更轻松地维护和修改系统。
3.6 Flyweight-享元模式
旨在通过在对象之间共享公共数据来最大程度地减少内存的使用。这是通过创建可由多个对象使用的共享对象来完成的，而不是每个对象都有自己单独的数据实例。
图 11： 享元模式 UML。
- 我们可以减少应用程序的内存占用并提高其性能。
- 仔细考虑节省内存的好处与实现模式增加的复杂性之间的权衡。
3.7 Proxy-代理
提供客户端和真实主体之间的中间对象。
代理模式可用于：
图 12： 代理 UML。
- 为可能昂贵或资源密集型的对象提供占位符。代理只能在需要时用于创建真实对象，而不是预先创建它。
- 控制对真实主题的访问。代理可用于强制实施访问限制或实施身份验证和授权检查。
- 为真实主题添加附加功能。代理可用于拦截对真实主体的请求，并在转发请求之前或之后执行其他任务。
4. 行为模式
4.1 Chain of Responsibility-责任链
允许对象向对象链发送请求以处理请求。
图 13：责任链 UML。
- 适用于多个对象可能能够处理一个请求的情况，并且事先不知道应处理请求的特定对象。
- 允许在不中断整体功能的情况下轻松地从链中添加或删除对象。
4.2 Command-命令
允许将请求封装为对象，然后可以将其传递给接收方执行。
图 14： 命令 UML。
- 允许将请求的发送方和接收方分开。
- 能够对请求进行排队或记录，并支持撤消/重做功能。
4.3 Iterator-迭代器
允许客户端按顺序访问聚合对象的元素，而无需公开对象的基础表示形式。
图 15： 迭代器 UML。
- 允许客户端以一致、统一的方式遍历对象集合，而不考虑集合的具体实现。
4.4 Mediator-调解员
允许多个对象相互通信，而无需知道其实现的详细信息。
图 16： 调解器 UML。
- 它提供了一个称为中介的中心通信点，它充当对象之间的中介。
- 在有大量对象需要相互通信的情况下很有用，因为它通过将通信逻辑与对象本身分开来降低系统的复杂性。
4.5 Observer-观察者
允许对象（主体）在其状态更改时通知一组对象（观察者）。观察者模式也称为发布-订阅模式。
图 17： 观察者 UML。
- 当您希望确保各种对象彼此保持同步时，或者当您希望能够彼此独立地重用主体和观察者时，非常有用。
4.6 Strategy-策略
允许对象通过切换到其他策略对象在运行时更改其行为或策略。
图 18： 策略 UML。
- 许多相关类之间的唯一区别是它们的行为。
- 需要算法的多个版本或变体。
- 算法访问或利用调用代码不应公开的数据。
- 类的行为应在运行时定义。
- 条件语句很复杂且难以维护。
4.7 Template Method-模板方法
定义算法的步骤，并允许子类重写某些步骤，同时仍保留算法的整体结构。
图 19： 模板方法 UML。
- 需要算法的单个抽象实现。
- 子类之间的常见行为应本地化为公共类。
- 父类应该能够统一调用其子类中的行为。
- 大多数或所有子类都需要实现该行为。
本文标签： 常用设计模式UML图示
版权声明：本文标题：常用设计模式UML图示 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：http://it.en369.cn/jiaocheng/1747965716a2234753.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。
发表评论