六大设计原则

从今天开始， 开始讲解设计模式，首先会讲解设计原则，如果没有看前言的伙伴可以去看一下简介

设计模式和设计模式七大原则-基于项目实战落地-CSDN博客

单一职责原则

单一职责原则，强调职责的分离，一个类只需要负责一种职责即可。这里大家可以根据学过的SpringBoot和SpringMVC来理解。SpringBoot的启动类是不是只负责项目的启动；SpringMVC的三层架构，也是单一职责原则的体现，Controller层只负责接入接口，Service层负责编写业务逻辑代码，Mapper层负责编写与数据库进行交互的代码。

接口隔离原则

刚接触接口隔离原则，也许会有人会觉得“隔离”不就是上一种原则“单一职责原则”吗？“隔离”就是对接口进行划分，上面一种原则“单一职责原则”不就是对接口进行划分吗？事实上，单一职责原则就是接口隔离原则的基础，单一职责原则注重的是职责的划分，从职责角度进行类和接口的划分；在此基础上，接口隔离原则注重接口使用的“准确性”和“最小化”；主要体现在两个方面：

不要使用没有任何依赖关系的接口

即就是如果这个类不依赖某个接口那么就不要使用该接口，需要使用哪个接口时按需使用即可。

一个类对另外一个类的依赖性应当是建立在最小的接口上的

通常来说，一个接口代表一个角色，不应该将不同的角色都交给一个接口，如果将没有关系的接口合并在一起，会形成一个臃肿的接口。以ArrayList源码为例

public class ArrayList<E> extends AbstractList<E> implements List<E>, RandomAcess, Cloneable, java.io.Serializable{
    ...
}

上述代码中，按职责划分了不同的接口，符合单一职责原则，在此基础上，接口隔离原则发挥作用，根据需要细化接口中的方法，保持接口的纯洁性，在满足需求的前提下，尽量减少接口的方法，做到专业、精确、最小化接口。

里氏替换原则

里氏替换原则是一种针对子类和父类关系的设计原则。该原则需要注意以下几点：

（1）子类需要实现父类中的所有抽象方法，为实现替换做好准备

实际上，这一点就是学习JavaSE时讲到的多态，在方法设计参数的时候，将参数设为父类型，然后，实际使用时，根据需要可以传入父类型的子类，这不就是多态吗，所以只是我们学习的时候，没有这样叫而已，实际上这个原则我们一直在遵守并履行。

（2）子类方法可以加入自己的特有方法以及属性

这同样是我们在学习javaSE时学习过的知识，子类继承父类后，除了拥有从父类继承来的方法和属性（不是private修饰的方法和属性），还可以根据实际需要自己加入特有的方法，对功能进行扩展，并且父类是不能使用子类中特有的方法的，这里也不在过多赘述。

这里重点阐述一下，子类从父类中继承的方法，理论上可以扩大参数类型，但是这样会失去里氏替换原则的“灵魂”，在子类中放大参数类型后，将导致子类中的方法不会再覆盖父类中的方法，导致失去替换这一重要作用。

以下是示例代码：

public class Demo{

    public static void main(String[] args){
        // 创建父类对象，入参是ArrayList
        BaseClass baseClass = new BaseClass();
        baseClass.process(new ArrayList);
        // 创建子类对象，入参是ArrayList
        SubClass subClass = new SubClass();
        subClass .process(new ArrayList);
    }

    
}
class BaseClass{
    public void process(ArrayList list){
        System.out.print("BaseClass take process!");
    }
}
class SubClass {
    public void process(List list){
        System.out.print("SubClass take process!");
    }
}

执行上述代码，会发现输出两次“BaseClass take process!”，原因是，子类中的process方法入参类型方法为了List，即使子类对象调用process方法，依然会执行父类中的方法，不妨细想一下，这样的效果还能达到替换的效果吗，显然是不能达到的，因此在实际开发中，不要轻易改变从父类中继承来的方法参数类型，这中操作实际上是方法“重载”（方法名称一致，返回值一致，方法入参不一致）的障眼法，实际上，JVM中，方法参数的“静态类型”是在编译器就早已经确定好了的，所以在编译阶段，Java编译器会根据参数的“静态类型”决定使用哪个方法，所以上述代码中传参都是ArrayList执行的都是父类中的方法。

那么，应该如何重写父类中的方法，答案是使用@Override注解，并且方法名，参数类型，返回值都保持一致即可。

依赖倒置原则

简单的说，就是面向接口编程，不要面向具体编程，这在Spring中体现的非常明显，相信学习过Spring的同学都能深刻体会到依赖倒置原则的使用，不再赘述。

迪米特原则

迪米特原则就是一个类对于其他类知道的越少越好，又称为最少知识原则，简单地说，就是只暴露接口方法入口，而对于内部实现，对于调用者来说是隐藏的。可以很大限度地保证系统的安全性、稳定性。在后续的设计模式讲解中会体现这一点，到时我再具体展开说，相信到那时，一定理解的会更深刻。

开闭原则

开闭原则，对扩展开放，对修改关闭，旨在提高代码的扩展性，提供系统的可维护性，稳定性。同样，空口无凭，我会在后续讲解设计模式时具体说明开闭原则的应用。

合成复用原则

合成复用原则又称之为组合/聚合原则，从名称中可以看出，在涉及到与其他类的关系时，优先使用聚合，关联的方式，其次考虑继承的方式，以降低耦合度。在Springboot中通过注解@Autowired注入对象的方式就是遵循的合成复用原则，试想如果采用继承的方式，那么在Controller中需要继承Service，然后在Controller中使用service中方法，如果这样，那么类与类之间的耦合度非常高，当系统规模庞大后，程序会非常不易于维护。

好了，设计原则的内容告一段落，接下来的内容是对设计模式的实战讲解，感兴趣的伙伴可以点进主页查看相关内容。