java设计模式

首先，什么是设计模式

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

模式: 在某些情况下，这是对某种类型问题的一般解决方案.

场景: 项目所在的环境

问题: 约束，项目目标等

解决方案: 通用且可重复使用的设计，解决了达到目标的约束.

二，三类设计模式

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

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

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

如下所示:

三个，每个类别中模型的关键点

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

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

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

抽象工厂: 在不显式指定具体类的情况下创建相关或依赖对象的族.

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

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

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

组合模式: 将对象组合到树形结构中以表示“部分到整个”层次结构.

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

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

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

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

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

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

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

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

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

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

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

介体模式: 使用介体对象封装一系列对象交互.

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

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

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

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

四个，概述23种设计模式

1. 单例模式

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

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

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

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

2. 工厂方法模式

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

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

3. 抽象工厂模式

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

4. 模式

对于构建器模式，它主要将复杂对象的构造和表示分开，以便相同的构造过程可以创建不同的表示. 适用于这些产品对象的内部结构相对复杂.

构建器模型将复杂产品的构建过程封装并分解为不同的方法，这使得创建过程非常清晰，并使我们能够更精确地控制复杂产品对象的创建过程. 它还将复杂产品对象的创建和使用隔离开来，以使同一创建过程能够创建不同的产品. 但是，如果产品的内部结构过于复杂，则会导致整个系统变得非常大，不利于控制. 同时，如果多个产品之间存在较大差异，则构建器模型不适用. 毕竟，这个世界的存在并没有太多相同的重点的产品，因此其使用受到限制. 其UML:

5. 原型模式

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

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

模式结构

原型模式包含以下字符:

原型: 抽象的原型类

ConcretePrototype: 具体的原型类

客户端: 客户端类

6. 适配器模式

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

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

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

目标: 目标抽象类

适配器: 适配器类

适配器: 适配器类

客户端: 客户端类

7. 桥接模式

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

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

桥接模式包括以下角色:

抽象: 抽象类

RefinedAbstraction: 扩展的抽象类

实现者: 实现类接口

ConcreteImplementor: 具体的实现类

8. 组合模式

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

尽管组合模式可以清楚地定义层次结构的复杂对象，并且还使添加新组件更加容易，但是这导致系统的设计变得更加抽象，如果系统业务规则更加复杂，则使用组合模式会有一定的挑战.

模式结构

组合模式包括以下角色:

组件: 抽象组件

叶子: 叶子成分

复合: 容器组件

客户端: 客户端类

9. 装饰模式

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

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

模式结构

装饰模式包含以下字符:

组件: 抽象组件

ConcreteComponent: 具体组件

装饰器: 抽象装饰类

ConcreteDecorator: 特定的装饰类

10. 外观模式

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

外观模式包含以下字符:

门面: 外观字符

子系统: 子系统角色

11. 恒源模式

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

Flyweight模型包括以下角色:

Flyweight: 抽象的Flyweight类

ConcreteFlyweight: 具体的轻量级类

UnsharedConcreteFlyweight: 非共享的具体flyweight类

FlyweightFactory: Flyweight工厂类

12. 代理模式

代理模式是为对象提供代理，并且代理对象控制对原始对象的引用. 它可以防止客户直接与实际目标进行沟通. 代理对象是目标对象的代表，其他需要处理目标对象的操作是与代理对象进行协商.

代理对象可以充当客户端和目标对象之间的中介，起到一定的作用并保护目标对象，并在一定程度上降低系统耦合度.

代理模式包括以下角色:

主题: 抽象主题人物

代理: 代理主题角色

RealSubject: 真实主题人物

13. 访客模式

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

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

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-201874-1.html