【更新中...】23中设计模式合集

幸运淦淦

已于 2024-01-29 02:36:18 修改

阅读量920

点赞数 18

文章标签： c# 设计模式 java 单例模式设计规范

于 2023-12-29 13:37:36 首次发布

本文链接：https://blog.csdn.net/u014685437/article/details/135253144

版权

@TOC

快速掌握只需要看代码理解与总结就够了

一、设计模式

1.设计模式简介

每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。

设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。

2.七大设计原则

在这里插入图片描述

二、面向对象设计原则

1.面向对象设计模式与原则

面向对象设计模式描述了面向对象设计过程中、特场景下、类与相互通信的对象之间常见的组织关系

❓对象是什么 ?

从概念层面讲，对象是某种拥有责任的抽象
从规格层面讲，对象是一系列可以被其他对象使用的公共接口
从语言实现层面来看，对象封装了代码和数据

❓有了这些认识之后，怎样才能设计“好的面向对象”?

遵循一定的面向对象设计原则
熟悉一些典型的面向对象设计模式

2.编程设计原则

针对接口编程，而不是针对实现编程
客户端无需知道所使用对象的特定类型。只需要知道对象拥有客户端所期望的接口。

比方说：假设我们有一个动物园，里面有各种动物，如狮子、老虎、熊等。每种动物都有自己的叫声。如果我们针对实现编程，那么当我们想听到动物的叫声时，我们需要为每种动物创建一个方法。但是，如果我们针对接口编程，我们只需要创建一个接口，比如Animal，并在接口中定义一个方法makeSound()。然后，每种动物都实现这个接口，并提供自己的makeSound()方法的实现。这样，无论我们添加多少种动物，我们都可以使用相同的方法来听到它们的叫声。

优先使用对象组合，而不是类继承
类继承通常为"黑箱复用"，对象组合通常为"黑箱复用"。继承在某种程度上破坏了封装性，子类父类耦合度高；而对象组合则只要求被组合的对象具有良好定又的接口，耦合度低。

比方说：当我们使用继承时，子类与父类之间的关系非常紧密，任何对父类的修改都可能影响到子类。如果父类的内部实现发生了改变，那么子类的行为也可能会受到影响，这就破坏了封装性。此外，继承还可能导致类的设计过于复杂，因为子类不仅需要实现自己的逻辑，还需要理解和维护父类的逻辑。
相比之下，组合/聚合则可以使得类之间的关系更加松散，提高了代码的灵活性。我们可以将一个类的对象作为另一个类的成员，这样，如果需要修改某个类的行为，我们只需要替换这个成员对象即可，而不需要修改类的内部实现。这样就降低了类之间的耦合度，提高了代码的可维护性。

封装变化点
使用封装来创建对象之间的分解层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次见的松耦合。

比方说：举个例子，假设我们正在设计一个电商系统，系统中有一个订单处理模块。这个模块的一个主要职责是计算订单的总价。然而，订单的价格计算规则可能会经常变化，比如可能会有各种不同的折扣和优惠活动。如果我们将价格计算的逻辑直接写在订单处理模块中，那么每次规则变化时，我们都需要修改订单处理模块的代码。这不仅会增加维护的难度，而且还可能会引入错误。相反，如果我们将价格计算的逻辑封装到一个单独的对象中，那么每次规则变化时，我们只需要替换这个对象即可，而不需要修改订单处理模块的代码。

使用重构得到模式——设计模式的应用不宜先入为主
一上来就使用设计模式是对设计模式最大的误用，没有一步到位的设计模式。

3.编程具体设计原则

单一职责原则(SRP)
一个类应该仅有一个引起它变化的原因
例如：一个处理报告的类应该只负责生成报告，而不应该同时负责打印报告。这两个功能应该由两个不同的类来处理。
开放封闭原则 (OCP)
类模块应该是可扩展的，但是不可修改《对扩展开放，对更改封闭》
例如：如果我们有一个计算形状面积的类，当我们需要添加一个新的形状时，我们应该能够添加一个新的形状类，而不需要修改计算面积的类。
Liskov 替换原则 (LSP)
子类必须能够替换它们的基类
例如：如果我们有一个动物类和一个鸟类（鸟类是动物类的子类），那么在任何需要动物的地方，我们都应该能够使用鸟类。
依赖倒置原则(DIP)
高层模块不应该依赖于低层模块，二者都应该依赖于抽象抽象不应该依赖于实现细节，实现细节应该依赖于抽象。
例如：一个电脑类不应该直接依赖于具体的CPU类或内存类，而应该依赖于抽象的CPU接口和内存接口
接口隔离原则(ISP)
不应该强迫客户程序依赖于它们不用的方法
例如：如果我们有一个多功能打印机类，它有打印、扫描和复印的功能，那么对于只需要打印功能的客户程序，我们不应该强迫它依赖于扫描和复印的方法，而应该提供一个只包含打印方法的接口。这样，客户程序就只需要依赖于这个接口，而不需要知道其他不相关的方法。

4.设计模式分类

两个角度
从目的来看：
创建型(Creational) 模式：负责对象创建
结构型(Structural) 模式：处理类与对象间的组合。
行为型 (Behavioral) 模式：类与对象交互中的职责分配
从范围来看：
类模式处理类与子类的静态关系。
对象模式处理对象间的动态关系。

三、Singleton 单例模式

1.核心思想

在单例模式中，类的唯一实例应该在第一次需要时创建，并且在后续的请求中重复使用，而不是每次请求时都创建新的实例

保证一个类仅有一个实例，并提供一个该实例的全局访问点。

2.代码理解

在这里插入图片描述
多线程情况下：

静态创建实例 or 静态构造器：

静态构造函数： 就像一个自动开关，当你第一次使用这个类（比如创建一个新的实例或者调用一个静态成员）的时候，它就会自动运行一次，然后就不再运行了。

静态实例的创建： 就像一个预先准备好的礼物，当你的程序开始运行并且第一次遇到这个类的时候，这个礼物就已经被准备好了。

所以说他们只会调用一次，以确保单例模式只有一个引用实例。只不过前者是用到的时候才会去调用，后者是从一开始就创建好，实际上也就是饿汉式与懒汉式

3.个别要点

Singleton模式中的实例构造器可以设置为protected以允许子类派生。
在父子类里面就算我多态创建一个实例，这个实力也同样是调用父类的构造器，所以可以说本质上还是单例模式，没什么区别
Singleton模式一般不要支持ICloneable接口，因为这可能会导致多个对象实例，与Singleton模式的初衷违背。
Singleton模式一般不要支持序列化，因为这也有可能导致多个对象实例，同样与Singleton模式的初衷违背。
在反序列化过程中，readObject()方法会创建一个新的对象。这个新的对象是通过调用无参构造函数创建的，然后将序列化时保存的字段值赋给新对象的对应字段。因此，反序列化后得到的对象与原来序列化的对象是不同的实例，即使它们的字段值是相同的
Singletom模式只考虑到了对象创建的管理，没有考虑对象销毁的管理。就支持垃圾回收的平台和对象的开销来讲，我们一般没有必要对其销毁进行特殊的管理
不能应对多线程环境：在多线程环境下，使用Singleton模式仍然有可能得到Singleton类的多个实例对象
将一个实例扩展到n个实例，例如对象池的实现
将new 构造器的调用转移到其他类中，例如多个类协同工作环境中，某个局部环境只需要拥有某个类的一个实例。
理解和扩展Singleton模式的核心是“如何控制用户使用new对一个类的实例构造器的任意调用”

4.解决了什么问题？

未必节省资源 C#中new一个对象通常是 “ 即时创建 > 使用 > 释放 ” 单例模式创建后就会一直保存与内存中，所以说是否节省资源仁者见仁智者见智。根据具体情况来决定。

同一个实例，也不能解决多线程并发问题 测试理解中有详情

单例真正解决的问题是：程序只需要这个对象实例化一次，只允许实例化
例如：数据库连接池：数据库连接–非托管资源–申请/释放消耗性能池化资源–内置10个链接—使用来拿，用完放回来–避免重复申请和销毁—控制链接数量

5.理解测试

最终Num的值应该为多少？
在这里插入图片描述

最终答案： 0 < Num and Num <= 10000
主要原因是因为，Num++这个操作本质有三个步骤，读取、修改、写回。这三个操作不具有原子性，从而导致线程冲突。