软件开发SOLID设计原则

前言：SOLID设计原则，不管是软件系统还是代码的实现，遵循SOLID设计原则，都能够有效的提高系统的灵活和可靠性，应对代码实现的需求变化也能更好的扩展和维护。因此提出了五大原则——SOLID。   我是通过老师讲解以及老师分享的笔记，然后加上自己的理解把它整理成笔记形式，分享给各位小伙伴一起学习！，同时也提升自己，巩固知识！

 

文章目录：

1. 单一职责原则（SRP）
2. 开闭原则（OCP）
3. 里氏替换原则（LSP）
4. 接口隔离原则（ISP）
5. 依赖倒置原则（DIP）

一、单一职责原则（SRP）

单一职责原则 (SRP)英文全称为 Single Responsibility Principle ，是最简单的原则，同样也是最难用好的原则之一，主要的原因是：‘单一职责原则的范围把控’；它的定义比较简单：‘对于一个类而言，应该仅有一个引起它变化的原因。引起了变化的原因就是表示了这个类的职责’；它可能是某个特定领域的功能，可能是某个需求的解决方案。这个原则表达的是不要让一个类承担过多的责任，一旦有了多个职责，那么它就越容易因为某个职责而被更改，这样的状态是不稳定的，不经意的修改很有可能影响到这个类的其他功能。因此，我们需要将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，不同类之间的变化互不影响。

简单理解就是： 一类或者模块应该有且只有一个变化的原因，而不应该有多个原因。

看下面的刀叉图会更好的理解：

先写一个违反单一原则的代码例子：

//我在这里定义一个鸡类抽象类

public abstract class Chickents{

    
    //来个鸡叫
    public void cockcsrow(){
  
        System.out.println("我会鸡叫");
    }
    

     //来个鸭叫
        
    public void cockcsrow(){
  
        System.out.println("我会鸭叫");
    }

}

看上上面代码，有没有发现问题，我上面备注的是，专门给鸡类定义一个抽象类，也就是我这个抽象类必须是和鸡相关的，里面的方法也是只能和鸡相关的，不能包含其他的；但是，我这个类下面还有一个方法和鸭有关；这就说明了，我这个类违反了单一职责原则 ；

正确的写法：

//定义一个鸡类的抽象类
public abstract class Chickens{
     public void cockscrow(){

        System.out.println("我会鸡叫");
    }

}

一个类只有一个职责，（和一个原因被更改）

二、开闭原则（OCP）

开闭原则 (OCP) 英文全称为 Open-Closed Principle，基本定义是软件中的对象（类，模块，函数等）应该对于扩展是开放的，但是对于修改是封闭的。这里的对扩展开放表示添加新的代码，就可以让程序行为扩展来满足需求的变化；对修改封闭表示在扩展程序行为时不要修改已有的代码，进而避免影响原有的功能。要实现不改代码的情况下，仍要去改变系统行为的关键就是抽象和多态，通过接口或者抽象类定义系统的抽象层，再通过具体类来进行扩展。这样一来，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，达到开闭原则的要求。

简单理解就是：我买一只鸡拿在手上，我又想买多只鸡，这时候，手拿不下，我们应该买个麻袋，放到一起，提着麻袋，而不是简单的全拿在手上。

再简单点理解：

扩展开放：添加新的实现类是开放的
修改关闭：修改原有代码是关闭的

看下面图有助于理解：

下面我写个加减违反开闭原则的代码例子

  /***
     * 
     * @param a
     * @param b
     * @param po
     * 
     * 
     * 这里完成了加和减
     * @return
     */
    public Double Calculator(Double a ,Double b ,String po){
        //转换一下防止精度丢失
        BigDecimal s1 = new BigDecimal(String.valueOf(a));
        BigDecimal s2 = new BigDecimal(String.valueOf(b));
        if("+".equals(po)){
            return s1.add(s2).doubleValue() ;
        }else if("-".equals(po)){
            return s1.subtract(s2).doubleValue() ;
        }else {
          throw new RuntimeException("没有别的符号了");
        }

    };

通过上面的例子，加和减已经写完了，这个时候，老王跑过来说：我要加两个个乘除的功能，这个时候我们是不是又要在下面 else if ，那么问题来了，开闭原则 ‘对修改封闭’ ，就是我们在原有的代码，不能修改，我们做了修改，那么就是违反了开闭原则，我们该如何解决呢？我们创建一个接口就好了，注意，这个接口只针对计算，如果这个计算接口，还写了和计算不相关的代码，也就违反了单一原则。单一原则和开闭原则它们是同时存在的 ；

下面我写个不违反开闭原则的代码例子

1）定义一个针对计算的接口

/***
 * @Date(时间)2023-05-30
 * @Author 半杯可可
 *
 * 计算器接口
 */
public interface NewCalculator {
    
    //做加减乘除的方法

    public Double NewCal(Double number1,Double number2) ;



}

这个接口，创建好了，我们在们在创建一个类（可以是加法类，可以是减法类...），实现这个接口

2）创建个类

  2.1、加法类，进行加法运算

package com.lx.impl;

import com.lx.dom.NewCalculator;

import java.math.BigDecimal;

/***
 * @Date(时间)2023-05-30
 * @Author 半杯可可
 *
 * 加法运算
 */
public class ADDCalculator  implements NewCalculator {
    @Override
    public Double NewCal(Double number1, Double number2) {
        //转换BigDecimal防止双精度丢失
        BigDecimal a = new BigDecimal(String.valueOf(number1)) ;
        BigDecimal b = new BigDecimal(String.valueOf(number2)) ;

        return a.add(b).doubleValue();
    }
}

2.2、减法类，进行加法运算

package com.lx.impl;

import com.lx.dom.NewCalculator;

import java.math.BigDecimal;

/***
 * @Date(时间)2023-05-30
 * @Author 半杯可可
 *
 * 减法运算
 */
public class SubtractionCalculator implements NewCalculator {
    @Override
    public Double NewCal(Double number1, Double number2) {
        //转换BigDecimal防止双精度丢失
        BigDecimal a = new BigDecimal(String.valueOf(number1)) ;
        BigDecimal b = new BigDecimal(String.valueOf(number2)) ;

        return a.subtract(b).doubleValue();
    }
}

一个计算接口，我们通过类实现接口，再实现它的方法，当我们想实现加法功能的时候，我们创建一个加法类实现这个接口，通过接口的方法再实现相应的功能，想实现一个减法功能的时候，我们创建一个减法类实现这个接口再通过接口方法实现相应功能；这时老王过来说：实现一个乘除的功能；我们再创建两个乘除类实现接口，再通过接口方法实现相应功能 ；

三、里式替换原则 (LSP)

里式替换原则 (LSP) 英文全称为 Liskov Substitution Principle，基本定义为：在不影响程序正确性的基础上，所有使用基类的地方都能使用其子类的对象来替换。这里提到的基类和子类说的就是具有继承关系的两类对象，当我们传递一个子类型对象时，需要保证程序不会改变任何原基类的行为和状态，程序能正常运作。

简单理解就是：任何基类可以出现的地方，子类一定可以出现

看下图有助于理解：

这里我写一段违反里式替换原则代码实例：

1）创建一个类，实现某接口，类实现了所有接口的方法

package com.lx.violate.impl;

import com.lx.violate.TestInf;

/***
 * @Date(时间)2023-05-30
 * @Author 半杯可可
 */
public class TestIn implements TestInf {
    @Override
    public String si1() {
        return null;
    }

    @Override
    public String si2() {
        return null;
    }

    @Override
    public String si3() {
        return null;
    }

   @Override
    public String si3(name) {
       System.out.println(name+"你最帅");
        return null;
    }
}

通过上面的代码，我们可以看到，我们重载了一个si3()方法，问题来了，根据里式替换原则：‘尽量不要重载父类的方法，换句话就是子类可以扩展父类的功能，但不能改变父类原有的功能’

所以，我们这里不应该有重载方法的出现，如果想要添加新功能，可以在父类扩展一个方法。

正确的写法代码例子：

package com.lx.violate.impl;

import com.lx.violate.TestInf;

/***
 * @Date(时间)2023-05-30
 * @Author 半杯可可
 */
public class TestIn implements TestInf {
    @Override
    public String si1() {
        return null;
    }

    @Override
    public String si2() {
        return null;
    }

    @Override
    public String si3() {
        return null;
    }

}

这里只演示了一种最简单的例子，还有很多例子，就不一一展示了！

四、接口隔离原则（ISP）

接口隔离原则 (ISP) 英文全称为 Interface Segregation Principle，基本定义：客户端不应该依赖那些它不需要的接口。客户端应该只依赖它实际使用的方法，因为如果一个接口具备了若干个方法，那就意味着它的实现类都要实现所有接口方法，从代码结构上就十分臃肿。

简单理解就是：类所要实现的接口应该分解成多个接口，然后根据你所需要的功能去实现，并且在使用到接口方法的地方，用对应的接口类型去声明这个方法！

再简单点理解：

将一个大的接口拆分成多个小接口，根据需求去实现相应功能的接口。

看图有助于理解：

写一个违反接口隔离原则的代码例子：

1）创建接口

package com.lx.dom;

/***
 * @Date(时间)2023-05-30
 * @Author 半杯可可
 */
public interface TestInf {
    
    public void si1() ;
    public void si2() ;
    public void si3() ;
    
}

2）创建User1类实现接口

package com.lx.dom;

/***
 * @Date(时间)2023-05-30
 * @Author 半杯可可
 */
public class Users1 implements TestInf{
    @Override
    public void si1() {

    }

    @Override
    public void si2() {

    }

    @Override
    public void si3() {

    }
}

3）创建User2类实现接口

package com.lx.dom;

/***
 * @Date(时间)2023-05-30
 * @Author 家辉
 */
public class Users2 implements TestInf{
    @Override
    public void si1() {

    }

    @Override
    public void si2() {

    }

    @Override
    public void si3() {

    }
}

通过上面的代码，我们可以分析，我们只要有一个类要实现这个接口，我们就必须实现这个接口的所有方法，问题来了，如果我User2类只想实现这个接口的一个方法，这时候该怎么办呢？如果我这个User2类还要实现别的功能，该怎么办呢？在接口隔离原则不可能在这个接口中在扩展一个方法啊，如果扩展了，那么就违反了口隔离原则。

• JDK8提供了默认方法，相当于在接口中可以有一个默认的空实现，我们可以创建默认方法

• 当子类实现这个接口时，只需要按需实现即可，意思就是需要实现哪个

• 在创建一个新的接口

接口隔离原则：‘类所要实现的接口应该分解成多个接口，然后根据你所需要的功能去实现，并且在使用到接口方法的地方，用对应的接口类型去声明这个方法’

正确的接口隔离原则的代码例子：

 1、创建TestInf接口

package com.lx.dom;

/***
 * @Date(时间)2023-05-30
 * @Author 半杯可可
 */
public interface TestInf {

    /**
     * JDK8提供了默认方法，相当于在接口中可以有一个默认的空实现，
     * 当子类实现这个接口时，只需要按需实现即可，意思就是需要实现哪个
     * 方法就重写哪个方法
     */
    default void methodA(){}
    default void methodB(){}
    default void methodC(){}

}

 2、创建User2Inf接口

package com.lx.dom;

/***
 * @Date(时间)2023-05-30
 * @Author 半杯可可
 */
public interface User2Inf {
    public void ma() ;
}

3、创建User2类实现TestInf,User2Inf两个接口

package com.lx.dom;

/***
 * @Date(时间)2023-05-30
 * @Author 半杯可可
 * 
 * 在实现多一个User2Inf接口，针对User2类的接口
 */
public class User2 implements TestInf,User2Inf{

    @Override
    public void methodB() {
        TestInf.super.methodB();
    }

    @Override
    public void ma() {
        System.out.println("你们最帅/美");
    }
}

基于接口隔离原则，我们需要做的就是减少定义大而全的接口，类所要实现的接口应该分解成多个接口，然后根据所需要的功能去实现，并且在使用到接口方法的地方，用对应的接口类型去声明，这样可以解除调用方与对象非相关方法的依赖关系

五、依赖倒置原则 (DIP)

依赖倒置原则 (DIP) 英文全称 Dependency Inversion Principle, DIP)，基本定义是：

• 高层模块不应该依赖低层模块，两者应该依赖抽象；

• 抽象不应该依赖细节，细节应该依赖抽象。

这里的抽象就是接口和抽象类，而细节就是实现接口或继承抽象类而产生的类。如果高层模块依赖于低层模块，那么低层模块的改动很有可能影响到高层模块，从而导致高层模块被迫改动，这样一来让高层模块的重用变得非常困难。因此可以在高层模块构建一个稳定的抽象层，并且只依赖这个抽象层；而由底层模块完成抽象层的实现细节。这样一来，高层类都通过该抽象接口使用下一层，移除了高层对底层实现细节的依赖。

简单理解就是：高层、底层两个模块依赖抽象，抽象不依赖细节，细节则依赖抽象；

再简单点：不应该依赖于具体实现，而是依赖于抽象；

看图更好理解：

总结：

• 单一职责原则（SRP）
  • 控制类的颗粒大小，减少不相关代码功能的耦合，让类更加健壮；
• 开闭原则（OCP）
  • 有了开闭原则，面向需求的各种变化能够进行快速的调整实现功能，提高了系统的灵活性、维护性、重用性；缺点就是会增加一定的‘复杂性’；
• 里氏替换原则（LSP）
  • 里氏替换原则目的就是要保证继承关系的正确性，所有子类的行为功能必须和使用者对其父类的期望保持一致，如果子类达不到这一点，那么必然违反里氏替换原则 ；
• 接口隔离原则（ISP）
  • 接口隔离原则主要功能就是控制接口的粒度大小，防止暴露给客户端无相关的代码和方法，保证了接口的高内聚，降低与客户端的耦合 ；
• 依赖倒置原则（DIP）
  • 依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性 ；
  • 依赖倒置原则是框架设计的核心原则，善于创建可重用的框架和富有扩展性的代码 ；