首页 > 操作系统 >

Java 23设计模式

电脑杂谈　发布时间：2020-03-24 00:20:06　来源：网络整理

c语言编程软件vc_c语言和c++和vc_vc知识库c++设计模式

设计模式是对代码设计经验的总结，该经验已被重复使用，大多数人都知道，分类和分类. 设计模式用于重用代码，使其他人更易于理解，并确保代码的可靠性. 毫无疑问，设计模式对他人和系统都是双赢的. 设计模式使代码编译真正成为工程. 设计模式是软件工程的基石，就像建筑物的砖石一样. 在项目中合理使用设计模式可以完美解决许多问题. 每种模式都有对应的原理. 每种模式都描述了一个反复出现在我们周围的问题，以及该问题的核心. 解决方案，这就是为什么它可以被广泛使用的原因. 简单地说:

模式: 在某些情况下，是解决特定类型问题的常规解决方案.

场景: 项目所在的环境

问题: 约束，项目目标等

解决方案: 通用，可重复使用的设计，解决实现目标的约束.

两三种设计模式

创建模式: 对象实例化的模式. 创建模式用于解耦对象的实例化过程.

结构模式: 组合类或对象以形成更大的结构.

行为模型: 类和对象如何交互，以及划分职责和算法.

如下所示:

每个类别中模式的三个关键点

单例模式: 一个类只能有一个实例，提供一个全局访问点.

简单工厂: 工厂类根据传入的参数来确定要创建产品类的哪个实例.

Factory方法: 定义用于创建对象的接口，并让子类确定要实例化的类.

抽象工厂: 创建相关或依赖对象的族，而无需显式指定具体类.

构建器模式: 封装了一个复杂对象的构建过程，可以分步进行构建.

原型模式: 通过复制现有实例来创建新实例.

适配器模式: 将类的方法接口转换为客户所需的另一个接口.

组合模式: 将对象分组为树形结构，以表示“整个”的层次结构.

装饰模式: 向对象动态添加新功能.

代理模式: 为其他对象提供代理，以控制对该对象的访问.

恒源（苍蝇量）模式: 通过共享技术有效地支持大量细粒度的对象.

外观模式: 为从外部访问子系统中的一组接口提供了一种统一的方法.

桥接模式: 将抽象部分与实现部分分开，以便可以独立更改它们.

模板模式: 定义算法结构，并推迟一些步骤来实现子类.

解释器模式: 给定一种语言，定义其语法的表示形式，并定义一个解释器.

策略模式: 定义一系列算法，对其进行封装，并使它们彼此可替换.

状态模式: 允许对象在其内部状态更改时更改其行为.

观察者模式: 对象之间的一对多依赖性.

备注模式: 在不破坏包装的情况下保持对象的内部状态.

介体模式: 一系列对象交互由中间对象封装.

命令模式: 将命令请求封装为一个对象，以便可以将不同的请求用于参数化.

访问者模式: 添加可作用于一组对象元素的新功能，而无需更改数据结构.

责任链模型: 分离请求的发送者和接收者，以便多个对象有机会处理请求.

迭代器模式: 一种遍历和访问聚合对象中各个元素而不暴露对象内部结构的方法.

四种，总共23种设计模式

1. 单例模式

Singleton模式，其定义是确保一个类只有一个实例，并提供一个全局访问点.

单例模式具有三个典型特征: 1.仅存在一个实例. 2.自我说明. 3.提供一个全局访问点.

因此，当系统中仅需要一个实例对象或系统中仅允许一个公共访问点时，除了该公共访问点之外，无法通过其他访问点访问该实例，因此可以使用单例模式

c语言和c++和vc_vc知识库c++设计模式_c语言编程软件vc

单例模型的主要优点在于，它可以节省系统资源并提高系统效率，同时还可以严格控制客户对其的访问权限. 可能是因为系统中只有一个实例，这导致单例类承担过多的职责，违反了“单一职责原则”，并且没有抽象类，因此很难进行扩展. UML非常简单，只有一个类，如下所示:

2. 工厂方法模式

作为抽象工厂模式的孪生兄弟，工厂方法模式定义了一个用于创建对象的接口，但是子类确定了要实例化的类，这意味着工厂方法模式将实例化延迟到了子类.

工厂方法模型非常符合“打开和关闭原理”. 当需要添加新产品时，我们只需要添加特定的产品类别和相应的特定工厂，而无需修改原始系统. 同时，在工厂方法模式下，用户只需要知道生产产品的特定工厂即可. 它不需要与产品创建过程相关，甚至不需要知道特定的产品类名称. 尽管他非常符合“打开和关闭原则”，但是由于每次添加新产品时，都需要添加两个类别，这不可避免地导致系统复杂性的增加. 其UML:

3. 抽象工厂模式

所谓的抽象工厂模式是提供一个接口，用于创建相关或依赖对象的族，而无需显式指定具体类. 它允许客户使用抽象界面来创建一组相关产品，而不必担心特定产品的实际生产. 这样，可以使客户与特定产品脱钩. 它的优点是隔离具体类的生成，因此客户端不需要知道创建了什么，但是缺点是添加新行为会更加麻烦，因为在添加新产品对象时，接口需要还要改变. 以及下面的所有子类. UML如下:

4. 模式

对于构建器模式，主要是将复杂对象的构造与表示分离，以便同一构造过程可以创建不同的表示. 适用于这些产品对象的内部结构更加复杂.

构建器模式将复杂的产品构建过程封装和分解为不同的方法，使创建过程非常清晰，这使我们可以更精确地控制复杂产品对象的创建过程，并隔离复杂产品的创建和集成对象. 使用以便同一创建过程可以创建不同的产品. 但是，如果产品的内部结构过于复杂，则会导致整个系统变得非常庞大且难以控制. 同时，如果多个产品之间存在较大差异，则不适用构建器模式. 毕竟vc知识库c++设计模式，这个世界存在很少有两种产品具有相同的观点，因此其使用范围受到限制. 其UML:

5. 原型模式

在我们的应用程序中，某些对象的结构可能很复杂，但是我们需要经常使用它们. 如果我们此时继续创建新对象，将不可避免地消耗系统内存. 这时，我们需要使用原型. 用于克隆此复杂且经常使用的对象的模式. 因此，原型模式是使用原型实例指定要创建的对象的种类，然后通过复制这些原型来创建新对象.

主要在创建新对象的成本过高时使用. 它的主要优点是它简化了新对象的创建并提高了效率，而原型模式提供了简化的创建结构. UML:

模式结构

原型模式包含以下角色:

原型: 抽象的原型类

ConcretePrototype: 具体的原型类

客户端: 客户端类

6. 适配器模式

在我们的应用程序中，我们可能需要使用不同的接口传递两个类. 在不修改这两者的情况下，我们可能需要一些中间件来完成此连接过程. 该中间件是适配器. 所谓的适配器模式是将类的接口转换为客户期望的另一个接口. 它可以使原始的两个不兼容的接口无缝地完成对接.

作为中间件的适配器将目标类与适配器分离，从而增加了类的透明度和可重用性.

适配器模式包括以下角色:

目标: 目标抽象类

适配器: 适配器类

客户端: 客户端类

7. 桥接模式

如果可以从多个角度对系统进行分类，并且每个分类都可能更改，那么我们需要做的就是将这些多个角度分开，以便它们可以独立更改并减少耦合，分离过程将使用桥接模式. 所谓的桥接模式是将抽象部分与实现部分隔离，以便它们可以独立更改.

桥接模式将继承关系转换为关联关系，封装更改，完成去耦，减少系统中的类数，并减少代码量.

桥接模式包括以下角色:

抽象: 抽象类

RefinedAbstraction: 扩展抽象类

实现者: 实现类接口

ConcreteImplementor: 具体的实现类

8. 组合模式

c语言和c++和vc_vc知识库c++设计模式_c语言编程软件vc

组合模式将多个对象组合成一个树形结构，以表示“整体”的结构级别. 它定义了如何以递归方式组合容器对象和叶对象，以便客户在使用过程中无需区分它们，并且可以对它们进行一致的处理. 使用合成模式时要注意的一件事也是合成模式的最关键部分: 叶子对象和合成对象实现相同的接口. 这就是为什么组合模式可以一致地处理叶节点和对象节点的原因.

尽管合成模式可以清晰地定义不同级别的复杂对象，但是它也使添加新组件变得更加容易，但这导致了更抽象的系统设计. 如果系统的业务规则比较复杂，则使用组合模式存在一定的挑战.

模式结构

组合模式包括以下角色:

组件: 抽象组件

叶子: 造叶

复合: 容器组件

客户端: 客户端类

9. 装饰模式

我们可以通过继承和组合为对象添加行为. 尽管使用继承可以很好地具有父类的行为，但它有几个缺点: 首先，如果对象之间的关系很复杂，则系统变得复杂，不利于维护. 其次，很容易产生“类爆炸”现象. 第三，它是静态的. 在这里，我们可以使用装饰器模式解决此问题.

装饰器模式，它动态地将责任附加到对象上. 为了扩展功能，装饰器提供了一种更灵活的继承方法. 装饰器模式虽然可以动态地将责任附加到对象上，但它会产生许多小对象，从而增加了系统的复杂性.

模式结构

装饰图案包含以下字符:

组件: 抽象组件

ConcreteComponent: 具体组件

装饰器: 抽象装饰类

ConcreteDecorator: 混凝土装饰类

10. 外观模式

我们都知道，类之间的耦合度越低，可重用性越好. 如果两个类不必彼此通信，则不要让这两个类彼此直接相关. 如果需要调用，则内部的方法可以由第三方转发. 外观模式很好地诠释了这段文字. 外观模式提供了用于访问子系统中的一组接口的统一接口. 它将应用程序中子系统之间的相互依赖性降至最低. 它为子系统提供了一个简单的单一屏障，客户可以通过该屏障与子系统进行通信. 通过使用外观模式，简化了客户对子系统的引用，并实现了客户与子系统之间的松散耦合. 但这违反了“开放-封闭原则”，因为添加新子系统可能需要修改外观类或客户端源代码.

外观模式包含以下字符:

门面: 外观字符

子系统: 子系统角色

11. 恒源模式

在系统中，对象将导致过多的内存消耗，尤其是那些重复很多的对象，这是对系统资源的极大浪费. Flyweight模式提供了对象重用的解决方案. 它使用共享技术来重用相同或相似的对象. Flyweight模型是一种运行共享技术，可以有效地支持大量细粒度对象的重用. 系统使用少量对象，这些对象相对相似，状态变化很小，并且对象可以多次重用. 这里要注意的一件事: Flyweight模式要求可以共享的对象必须是细粒度的对象. Flyweight模式通过共享技术大大减少了系统中的对象数量. 同时，“举重”模式使用内部和外部状态. 同时，外部状态是相对独立的，不会影响内部状态. 因此，Flyweight模式可以使Flyweight对象在不同的上下文中共享. 同时，它分为内部状态和外部状态. Flyweight模式将使系统更加复杂，并且将导致读取外部状态的时间过长.

Flyweight包含以下字符:

Flyweight: 抽象的Flyweight类

ConcreteFlyweight: 具体的轻量级类

UnsharedConcreteFlyweight: 非共享的具体flyweight类

FlyweightFactory: Flyweight工厂类

12. 代理模式

代理模式是为对象提供代理，并且代理对象控制对原始对象的引用. 它可以防止客户直接与真正的目标受众进行交流. 代理对象是目标对象的代表. 需要处理此目标对象的其他操作正在与此代理对象进行协商.

代理对象可以充当客户端和目标对象之间的中介，在保护和保护目标对象方面发挥了作用，并且在一定程度上降低了系统的耦合程度. / p>

代理模式包括以下角色:

主题: 抽象主题人物

代理: 代理主题角色

RealSubject: 真实主题人物

c语言编程软件vc_vc知识库c++设计模式_c语言和c++和vc

13. 访客模式

访客模式通常被称为23种设计模式中最困难的一种. 除了结构复杂之外，还很难理解. 在我们的软件开发中，对于同一对象可能会有不同的处理方式. 如果我们都分别处理它们，将发生灾难性错误. 对于此问题，访问者模式提供了更好的解决方案. 访客模式表示作用在对象结构中每个元素上的操作. 它使我们能够定义对这些元素起作用的新操作，而无需更改每个元素的类.

访问者模式的目的是封装一些应用于某些数据结构元素的操作. 一旦需要修改这些操作，接受该操作的数据结构就可以保持不变. 为不同类型的元素提供多种访问操作，并且可以添加新操作而无需修改原始系统. 同时，我们需要弄清楚访问者模式适用于那些相对稳定的数据结构，因为它会将数据操作与数据结构分开. 如果系统的数据结构相对稳定，但是操作算法易于更改；如果是，则适用的访问者模式更合适，因为访问者模式使算法操作的增加变得更加容易.

访客模式包括以下角色:

访问者: 抽象访问者

ConcreteVisitor: 特定访问者

元素: 抽象元素

ConcreteElement: 特定元素

ObjectStructure: 对象结构

14. 模板模式

有时候，我们对某些事情执行相同的步骤，但差别很小. 在软件开发领域也是如此. 如果我们都一步一步地执行这些步骤，则将需要时间和精力. . 因此，我们可以分解，封装这些步骤，然后使用继承进行继承，当然，您可以重写不同的实现！这是模板方法模式提供的解决方案.

所谓的模板方法模式是在方法中定义算法的框架，并将某些步骤推迟到子类. 模板方法允许子类在不更改算法结构的情况下重新定义算法中的某些步骤.

模板方法模式基于继承的代码重用技术. 在模板方法模式中，我们可以将代码的相同部分放在父类中，并将不同的代码放在不同的子类中. 换句话说，我们需要声明一个抽象父类，以具体方法和具体构造函数的形式实现一些逻辑，然后声明一些抽象方法以允许子类实现其余的逻辑. 不同的子类可以以不同的方式使用. 实现此逻辑. 因此，模板方法的模板实际上是一种通用方法，但是该方法封装了算法实现的步骤.

模板方法模式包含以下角色:

AbstractClass: 抽象类

ConcreteClass: 具体的子类

15. 策略模式

我们知道，完成一件事情可能有很多方法，但是总有最有效的方法之一. 在软件开发领域也是如此. 我们也有很多方法来实现功能，但是我们需要一种简单有效的方法来实现它，从而使系统变得非常灵活. 这就是策略模型.

因此，策略模式是定义算法家族，分别封装这些算法，以便它们可以相互转换. 此模式独立于使用算法的客户更改算法.

在策略模式下，它将这些解决问题的方法定义为一个算法组，每种方法对应于一个特定的算法. 在这里，我将算法称为策略. 尽管策略模式定义了算法，但它不提供算法的选择，即哪种算法最适合什么问题. 这不是策略模式所关心的，因此策略的选择应由客户端来完成. 客户必须清楚地了解每种算法之间的区别，以及何时何地使用哪种策略最合适，这会加重客户的负担.

同时，策略模式也完全符合“开放与封闭原则”. 用户可以在不修改原始系统的情况下选择算法或行为，还可以灵活地添加新的算法或行为. 但是一个策略对应一个类别，系统将生成许多策略类别.