java设计模式（持续更新中）

1 设计模式介绍

设计模式代表了代码的最佳实践，被有经验的开发人员使用。
设计模式是很多被反复使用并知晓的，主要是对代码和经验的总结。
使用设计模式是为了重用代码，并让代码更容易被人理解，保证代码的可靠性。
对接口编程而不是对实现编程
有限使用对象组合而不是继承关心

2 设计模式七大原则

单一职责原则：一个类应该只有一个引起它变化的原因。
开闭原则：软件实体应对扩展开放，对修改封闭。
里氏替换原则：子类型必须能够替换掉它们的基类型。
依赖倒置原则：高层模块不应依赖于低层模块，两者都应依赖于抽象；抽象不应依赖于细节，细节应依赖于抽象。
接口隔离原则：使用多个专门的接口比使用单一的总接口更好。
合成/聚合复用原则：尽量使用对象的组合/聚合，而不是继承关系达到复用的目的。
迪米特法则（最少知道原则）：一个对象应对其他对象有尽可能少的了解。

原文链接：https://blog.csdn.net/m0_54187478/article/details/136165351

设计模式--七大原则 - 简书 (jianshu.com)

以下内容均是借鉴上诉链接

3、设计原则详解

3.1单一职责原则

单一职责原则（Single Responsibility Principle, SRP）指一个类应该仅有一个引起它变化的原因。这意味着一个类应该只负责一项职责。即一个类应该只负责一项职责。如类A负责两个不同职责：职责1，职责2。当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1、A2。

通俗地讲，单一职责原则就像是说，一个人只应该有一个工作。想象你有一个朋友，他既是厨师也是司机。如果有一天他因为烹饪而分心，导致开车出事了，那就是因为他承担了太多的责任。在编程中，如果一个类同时负责多件事情（比如，既存储数据又显示数据），那么当其中一部分需要改变时，很容易影响到其他部分。遵循单一职责原则，意味着每个类只负责一件事情，这样当需求变化时，只需修改有限的部分，减少错误，使代码更容易维护和理解。

3.2开闭原则

开闭原则（Open-Closed Principle, OCP）是面向对象设计的核心原则之一，它指出软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。这意味着在不修改现有代码的情况下，应该能够添加新功能。也就是当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。用抽象构建框架，用实现扩展细节。

开闭原则就像是给你的应用程序装上了一个"扩展插槽"，让你可以随时增加新功能而不需要打开机器去重新焊接电路板。想象一下，如果你有一个游戏机，每当出现新游戏时，你不需要更换游戏机内部的硬件就能玩，只需要购买新的游戏卡带插上去即可。这样，游戏机的设计就允许了扩展（新增游戏），而不需要修改（打开游戏机更换部件），这正是开闭原则的精髓。

3.3依赖倒置原则

依赖倒置原则（Dependency Inversion Principle, DIP）指的是高层模块不应该依赖于低层模块，两者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。这个原则的核心在于促进系统的解耦，从而使得系统更易于扩展和维护。（程序要依赖于抽象接口，不要依赖于具体实现）它是开闭原则的基础。

比如有个Person类，可以接受Email、QQ和微信的消息。如果都为其提供一个专门的方法，就会让代码非常的冗余：

可以引入一个IReceiver接口，让Person类依赖该接口。这样QQ、微信和Email各自实现IReceiver里面的方法即可：

依赖倒置原则（Dependency Inversion Principle, DIP）的核心思想是高层模块不应该依赖低层模块，它们都应该依赖于抽象；抽象不应该依赖细节，细节应该依赖抽象。用通俗的语言来说，就像是建筑的设计不应该基于具体的砖块类型，而是基于砖块的一般特性。这样，无论使用什么样的砖块，只要符合这些特性，就能构建出建筑。在编程中，这意味着我们的代码应该依赖于接口或抽象类，而不是具体的实现类，这样可以使代码更灵活、更易于维护和扩展。

3.4接口隔离原则

接口隔离原则（Interface Segregation Principle, ISP）强调不应该强迫客户依赖于它们不使用的接口。换句话说，更倾向于创建专门的接口而不是一个大而全的接口。

列如：类A通过接口i 依赖B，类C通过接口i 依赖类D，如果接口i对于类A和类C来说不是最小接口，那么类B和类D必须去实现他们不需要的方法。

按隔离原则应当这样处理：将接口i拆分为独立的几个接口，将类分别与他们需要的接口建立依赖关系，也就是采用接口隔离原则。

接口隔离原则（Interface Segregation Principle, ISP）讲的是不应该强迫客户依赖于它们不用的接口。用一个简单的例子来说，如果有一个多功能打印机，它可以打印、扫描和复印。根据接口隔离原则，我们不应该只有一个接口包含所有这些功能，因为不是每个使用打印机的人都需要扫描和复印的功能。相反，应该为打印、扫描和复印各自提供独立的接口。这样，只需要打印功能的用户就不必实现或依赖于扫描和复印的接口了。简而言之，接口隔离原则就是让接口更小、更专注，避免一个庞大的接口承担太多的职责。

3.5迪米特法则

迪米特法则（Law of Demeter, LoD），也称为最少知识原则，是一种软件开发的设计指导原则。它强调，一个对象应该对其他对象有尽可能少的了解，只与直接的朋友通信。直接的朋友指的是成员变量、方法参数或者对象创建的实例。

迪米特法则就像是说，一个人应该尽可能少地知道其他人的私事，只和直接的朋友交流。在编程中，这意味着一个类不应该知道太多其他类的细节，只和直接相关的类交互。这样做可以减少系统中的耦合，使得修改一个部分的时候，不会影响到太多其他部分，保持代码的整洁和可维护性。

3.6里氏替换原则

里氏替换原则(Liskov Substitution Principle)要求所有引用基类的地方必须能透明地使用其子类的对象。也就是在继承关系中，子类尽量不要重写父类的方法。继承实际上让两个类耦合性增强了，特别是运行多态比较频繁的时，整个继承体系的复用性会比较差。

比如一种极端情况：一个类继承了另一个类，但却重写了所有方法，那么继承的意义何在？说好的复用呢？

解决方法是把原来的父类和子类都继承一个更通俗的基类，在适当的情况下，可以通过聚合，组合，依赖等来代替。

3.7合成复用原则

合成复用原则(Composite Reuse Principle)就是是尽量使用合成/聚合的方式，而不是使用继承。

合成/聚合复用原则就像是搭积木。想象你正在建造一个小屋，你可以选择用预制的部分（比如窗户、门等）来组合成你想要的结构，而不是自己从头开始制造每一个部分。在编程中，这个原则告诉我们应该通过将现有的对象（积木块）组合起来来创建新的功能，而不是通过继承一个大而全的类（从零开始造一个整体）。这样做使得代码更加灵活，因为你可以随时替换或者重新组合这些"积木块"，而不是被固定在一种设计之中。

4、23种设计模式

4.1创建模式（5种）

4.1.1单例模式

**定义：**单例模式确保一个类只有一个实例，并提供一个全局访问点。

单例模式可以分为两种：饿汉式 和懒汉式

优点：

全局访问：提供了一个全局访问点，便于控制实例数量。
资源节约：避免了创建多个对象时的资源浪费。
线程安全：在多线程环境中，可以保证只创建一个实例。
控制实例化：可以控制对象的创建过程。

缺点：

代码耦合：单例模式可能会隐藏一些依赖关系，导致代码耦合。
可测试性差：由于单例模式是全局的，这使得单元测试变得困难。
内存浪费：单例对象在程序的整个生命周期内都占用内存。
滥用：单例模式有时会被滥用，导致程序设计不灵活。

适用场景：

需要确保在整个应用程序中只存在一个实例的情况，如配置管理器、线程池、缓存等。

方式一：饿汉式单例

XML 复制代码

/**
 * 预实例化单例类
 * 该类实现了Singleton模式，确保一个类只有一个实例，并提供对该实例的全局访问点
 * 使用静态预实例化方式，避免了同步加载的性能开销，适用于多线程环境
 */
public class PreloadSingleton {
    // 单例实例，静态成员变量，在类加载时完成实例化
    private static PreloadSingleton instance=new PreloadSingleton();

    // 私有构造方法，防止外部通过new创建实例
    private PreloadSingleton(){
        // 初始化操作（如果有的话）
    }

    /**
     * 获取单例实例的方法
     * @return PreloadSingleton的唯一实例
     */
    public static PreloadSingleton getInstance(){
        // 返回单例实例
        return instance;
    }
}

可以很明显看出这种方式，在没有使用该单例对象时，该对象就被加载到内存，会造成内存的浪费。但是这种方式没有线程安全。

方式二：懒汉式式单例

为了避免内存的浪费，我们可以采用懒加载，即用到该单例对象的时候再创建。

XML 复制代码

public class Singleton {
    // 单例实例，私有静态变量
    private static Singleton instance ;
    
    /**
     * 私有构造方法，防止外部实例化
     */
    private Singleton(){
        
    }
    /**
     * 获取单例实例的方法
     * 如果实例不存在，则创建一个新的实例并返回
     * 如果实例已经存在，则直接返回该实例
     * @return Singleton的唯一实例
     */
    public static Singleton getInstance(){
        if(instance == null){
            instance = new Singleton();
        }
        return instance;
    }
}

懒汉式虽然不浪费内存 ，但是无法保证线程的安全。首先，if判断以及其内存执行代码是非原子性的。当多线程执行时，可能会同时又多个线程，判断if(instance == null)是否处理，可能多个线程判断成立，那可能就会创建多个实例。

那如何保证线程安全呢？

相信很多人第一时间都会想到加synchronized关键字，synchronized加载getInstace()函数上确实保证了线程的安全。但是，如果要经常的调用getInstance()方法，不管有没有初始化实例，都会唤醒和阻塞线程。为了避免线程的上下文切换消耗大量时间，如果对象已经实例化了，我们没有必要再使用synchronized加锁，直接返回对象。

XML 复制代码

public class Singleton {
       private static Singleton instance = null;
       private Singleton() {
       };
       public static synchronized Singleton getInstance() {
              if (instance == null) {
                     instance = new Singleton();
              }
              return instance;
       }
}

这种方式可能会使性能收到影响，因为每次获取实例要加锁。解决思路：我们能不能在第一次创建的时间加锁，后续都不加锁呢。

XML 复制代码

public class Singleton {
    private static Singleton instance ;

   
    private Singleton(){

    }
    public static Singleton getInstance(){
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

上述方式也称"饿汉式双检锁"。这样就可以保证线程安全，也能保证性能。