前言

最近在做.net项目和学习这个设计模式中的依赖倒置和工厂方法，这个过程当中发现在开发这个.net项目中有很多不合理的地方，就是我们使用了接口，但是在前端开发的时候还是使用的new的方式去给接口实例化，这还是违背了依赖倒置的原则。因为项目中并没有使用spring这些相关的框架，只是一个简单的三层模式UBD，之前在java项目中因为直接使用了spring的框架而忽略了在这个问题。
这里声明一下本次的代码示例均为Java语言。.net实现思路和这个一模一样。

依赖倒置

定义

依赖倒置原则（Dependency Inversion Principle）是面向对象设计中的一个原则，它是SOLID原则中的一部分，由罗伯特·C·马丁（Robert C. Martin）提出。该原则强调了高层模块不应该依赖于低层模块的具体实现细节，而应该依赖于抽象接口。具体来说，依赖倒置原则有以下几个核心概念：

模块间的依赖关系应该通过抽象发生，而不是具体实现发生。这意味着高层模块和低层模块都应该依赖于抽象接口或抽象类，而不是具体的实现类。
抽象不应该依赖于具体实现。抽象接口应该定义在高层模块中，并且不应该受到具体实现类的影响。这样可以保持高层模块的稳定性和独立性。
具体实现应该依赖于抽象。具体实现类应该依赖于抽象接口或抽象类，通过实现抽象定义的方法来完成具体的功能。

通过遵循依赖倒置原则，可以提高系统的可维护性、扩展性和灵活性。它可以降低模块间的耦合度，使得系统更容易进行修改和测试。另外，依赖倒置原则也促进了面向接口编程（Interface-Oriented Programming）的实践，强调了定义良好的抽象接口和合理的接口设计。

需要注意的是，依赖倒置原则并不是要求完全避免依赖关系，而是通过合理的抽象和接口设计来管理和控制依赖关系，以提高系统的灵活性和可维护性。

不符合依赖倒置原则是什么样子


import com.example.onlystudent.DIPDemo.Dao.ItemDao;
import com.example.onlystudent.DIPDemo.Dao.ItemDao4MysqlImpl;

//B层实现类。
public class ItemManagerImpl {
    //作为B层，这里是直接依赖的D层的代码，可以看到使用的是D层的接口。
    // 但是还是在给接口实例化的时候使用到了具体的实现来，并且在这个B层的import中出现了实现类的相关信息。
    ItemDao itemDao=new ItemDao4MysqlImpl();
}

package com.example.onlystudent.DIPDemo.Dao;

//D层接口
public interface ItemDao {
	//仅做demo展示，并为声明任何方法 
}

package com.example.onlystudent.DIPDemo.Dao;

//D层接口的实现类，这里是一个MySQL语法的实现类
public class ItemDao4MysqlImpl implements ItemDao {
    	//仅做demo展示，并为声明任何方法 
}

package com.example.onlystudent.DIPDemo.Dao;
//D层接口的实现类，这里是一个Oracle语法的实现类
public class ItemDao4OracleImpl implements ItemDao{
	//仅做demo展示，并为声明任何方法 
}

在这套代码中虽然也声明了接口，也有实现类，但是在具体使用过程中并没有遵循依赖倒置原则。体现在上述的ItemManagerImpl类中，因为按照依赖倒置原则在ItemManagerImpl类中只能出现D层的ItemDao的信息。它应该只知道ItemDao，如果现在需要更换数据库，那么就需要更改ItemManagerImpl中的代码，将new ItemDao4MysqlImpl()修改为new ItemDao4OracleImpl()，但是这并不符合开闭原则，所以这里使用的这个依赖倒置并不完善，或者说是仅仅有了一个形式上的依赖倒置，但是本质上并没有改变ItemManagerImpl有依赖于具体实现类。

😄完善

如何修改上面的代码，做到符合依赖倒置的原则呢？这就需要用到反射这个强大的功能，首先要添加一个配置文件。
在配置文件中加上需要反射的类路径，在这个demo中需要反射的类是mysql实现类。
在这里插入图片描述
添加完配置文件中的信息后，需要有一个读取配置文件的类，来获取配置文件中的类路径信息

import java.io.FileInputStream;
import java.io.IOException;
import java.util.Properties;
/**
 * @Description: 读取配置文件
 */
public class PropertiesReader {
    public static String getValue(String key) {
        Properties properties = new Properties();
        FileInputStream fis = null;
        String value="";
        try {
            fis = new FileInputStream("application.properties");
            properties.load(fis);
            // 读取配置项
            value= properties.getProperty(key);
            return value;
        } catch (IOException e) {
            e.printStackTrace();
        } finally {

            if (fis != null) {
                try {
                    fis.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
        return value;
    }
}

有了以上的这些准备后，现在开始修改ItemManagerImpl这个类中的依赖问题

将new这个操作删除，修改为通过反射来获取对象。
通过使用反射加配置文件在构造函数中将itemDao给实例化出对象来。这样就符合了依赖倒置，这个时候在看ItemManagerImpl类中它的依赖中就只有ItemDao这个接口了。
在这里插入图片描述

后期项目中如果需要更换数据库，那这里去操作出数据库的类，就可以在配置文件中进行更换，只需将类路径更换即可。以上这些操作只是为了简单的描述出来，依赖倒置具体的实现和应用。实际开发过程中要考虑的还是很多的，比如对象怎么管理啊这些工作。

里式替换

定义

里氏替换原则的内容可以描述为： “派生类（子类）对象可以在程式中代替其基类（超类）对象。

具体应用

在上述的代码中其实就是基于里式替换实现的，虽然在定义中说是基类和派生类，但是接口同样适用里式替换的原则，根据里式替换原则，如果一个类通过实现一个接口来表达其行为，那么在使用接口时，任何实现该接口的类都应该能够替换该接口，而不会破坏程序的正确性。
具体体现在ItemDao itemDao=new ItemDao4MysqlImpl();虽然后面修改为了反射获取，通过类型转换为了ItemDao

itemDao=(ItemDao)Class.forName(PropertiesReader.getValue("itemDao")).newInstance();

但是这依然符合。

接口隔离

定义

接口隔离原则的核心思想是将庞大而臃肿的接口拆分为更小、更具体的接口，使得每个接口只包含客户端所需的方法。这样可以降低类和模块之间的耦合度，减少对不相关方法的依赖，提高代码的灵活性、可维护性和可复用性。
以下是接口隔离原则的几个要点：

接口应该精简而专注于特定的功能领域。不应该设计臃肿的接口，包含大量不相关的方法。
客户端不应该强制依赖于它不需要的接口。一个类或模块只应该依赖于它需要使用的接口，而不是依赖于多余的接口。
接口隔离原则鼓励根据不同的客户端需求定义多个小接口，而不是一个大而全的接口。这样可以提供更高的灵活性和可扩展性。
接口设计应该符合单一职责原则，即一个接口只负责定义一个单一的功能或角色。

具体应用

接口隔离原则在我们上述的依赖倒置这里其实就已经体现了，访问数据库的操作行为抽象为一个接口，这个接口包含了数据库操作的所有行为，而作为B层的ItemManagerImpl来说，它只依赖于接口，而具体的实现类单独写，如果后期需要添加信息的数据库，直接添加一个实现类即可，搭配着依赖倒置的原则和里式替换，通过反射去创建对象。程序的灵活性就大大提高了。
在这里插入图片描述