控制反转，依赖注入，依赖倒置傻傻分不清楚？-低调大师

控制反转，依赖注入，依赖倒置傻傻分不清楚？

2022-02-11 599

通过这篇文章，你将了解到

控制反转（IoC）是什么？「反转」到底反转了什么？
Spring和IOC之间是什么关系？
依赖注入（DI）和依赖倒置原则（DIP）又是什么？
IOC、DI和DIP有什么关系？

1. 控制反转（IoC）

1.1 一个典型案例

介绍「控制反转」之前，我们先看一段代码

public class UserServiceTest {
    public static boolean doTest() {
        //此处编写自己的判断逻辑
        return false;
    }

    public static void main(String[] args) {

        if (doTest()) {
            System.out.println("Test succeed.");
        } else {
            System.out.println("Test failed.");
        }
    }
}

如上，我们为一个方法写了一个测试用例，包括main方法的创建，所有的流程都是我们自己来控制的。

现在有这么一个框架，代码如下：

public abstract class TestCase {
    public void run() {
        if (doTest()) {
            System.out.println("Test succeed.");
        } else {
            System.out.println("Test failed.");
        }
    }

    public abstract boolean doTest();
}


public class JunitApplication {
    private static final List<TestCase> cases = new ArrayList();

    public static void register(TestCase testCase){
        cases.add(testCase);
    }

    public static void main(String[] args) {
        for(TestCase testCase : cases){
            testCase.run();
        }
    }
}

利用这么框架，我们如果再为UserServiceTest写一个测试用例，只需要继承TestCase，并重写其中的doTest方法即可。

public class UserServiceTestCase extends TestCase{
    @Override
    public boolean doTest() {
        //此处编写自己的判断逻辑
        return false;
    }
    
}

//注册测试用例
JunitApplication.register();

看完这里例子，相信读者朋友已经明白了这个框架给我们带来了怎样的便利。一开始我们需要为每个测试方法添加一个main方法，一旦待测试的方法多起来会非常的不方便。现在框架给我们制定了程序运行的基本骨架，并为我们预设了埋点，我们只需要设置好框架的埋点，剩下的执行流程就交给框架来完成就可以了。

这就是「框架实现控制反转」的典型例子。这里的「控制」指的是对执行流程的控制，「反转」指的是在框架产生之前我们需要手动控制全部流程的执行，而框架产生之后，有框架来执行整个大流程的执行，流程控制由我们「反转」给了框架。

1.2 IoC概念的提出

早在1988年，Ralph E. Johnson与Brian Foote在文章Designing Reusable Classes中提出了inversion of control的概念，他们怎么也没想到，这几个单词会在未来给中国的编程者造成多大的麻烦！

虽然Spring框架把IoC的概念发扬光大，但IoC的诞生远远早于Spring，并且IoC的概念正是在讨论框架设计的时候被提出来的。至于框架和IoC是先有鸡还是先有蛋，这个问题对我们并没有什么意义。

当IoC概念模糊不清的时候，追本溯源或许是让我们彻底理解这个概念的好想法。至于概念之外的延伸不过是细枝末节罢了。接下来我们体会一下文章中比较重要两段话，我进行了意译。

One important characteristic of a framework is that the methods defined by the user to tailor the framework will often be called from within the framework itself, rather than from the user's application code.

「框架」的一个重要特征是，框架本身定义的方法常常由框架自己调用，而非用户的应用程序代码调用。

This inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application. 这种「控制反转」使框架作为一个程序运行的骨架，具有了可扩展的能力。用户可以自定义框架中预设好的埋点。

IoC就是一种思想，而不是某种具体编程技术的落地。应用了「控制反转」思想的框架允许用户在一定程度上「填空」即可，其余的运行都交给框架。

1.3 为什么提出IoC

几乎所有编程思想的提出都是基于一个目的——解耦。Ioc是怎么解决耦合问题的呢？

假设我们有四个对象，彼此之间的依赖关系如图翻译成代码大致如下：

class A{
    Object b = new B();
    ...
}

class B{
    Object c = new C();
    Object d = new D();
    ...
}

class C{
    Object d = new D();
}

但是A对象就是实实在在地需要B对象啊，这种依赖关系无法被抹除，就意味着耦合关系不可能完全解除，但是可以减弱！IoC的思想是引入一个IoC容器来处理对象之间的依赖关系，由主动依赖转为被动依赖，减轻耦合关系，从强耦合变为弱耦合。关于IoC容器的作用，给大家举个生活中的例子。

假设有3个顾客分别从4个店铺购买了商品，好巧不巧，所有人都碰到了质量问题，在第三方购物平台诞生之前，每个顾客都只能分别与每家店铺协商理赔问题，此时顾客和店铺之间是强耦合关系。有了第三方购物平台之后，顾客可以直接和平台投诉，让平台和各个店铺进行协商，平台对每位顾客进行统一理赔，此时顾客和店铺之间就是松耦合的关系，因为最累的工作被平台承担了，此时平台的作用就类似IoC容器。最后拿Spring再举个例子。

从大粒度上看，使用Spring之后我们不需要再写Servlet，其中调用Servlet的流程全部交给Spring处理，这是IoC。

从小粒度上看，在Spring中我们可以用以下两种方式创建对象

// 方式1
private MySQLDao dao = new MySQLDaoImpl();

// 方式2
private MySQLDao dao = (MySQLDao) BeanFactory.getBean("mySQLDao");

使用方式1，dao对象的调用者和dao对象之间就是强耦合关系，一旦MySQLDaoImpl源码丢失，整个项目就会在编译时期报错。

使用方式2，如果我们在xml文件中配置了mySQLDao这个bean，如果源码丢失，最多报一个运行时异常（ClassNotFound错误），不至于影响项目的启动。

Spring提供了方式2这样的方式，自动给你查找对象，这也是IoC，而且这是IoC的常用实现方法之一，依赖查找。另一种是依赖注入，我们一会儿再介绍。

1.4 Spring和IoC的关系

Spring是将IoC思想落地的框架之一，并将之发扬光大的最著名的框架（没有之一）。

1.5 面试中被问到IoC怎么回答

「控制反转」是应用于软件工程领域的，在运行时被装配器对象用来绑定耦合对象的一种编程思想，对象之间的耦合关系在编译时通常是未知的。

在传统的编程方式中，业务逻辑的流程是由应用程序中早已设定好关联关系的对象来决定的。在使用「控制反转」的情况下，业务逻辑的流程是由对象关系图来决定的，该对象关系图由IoC容器来负责实例化，这种实现方式还可以将对象之间关联关系的定义抽象化。绑定的过程是由“依赖注入”实现的。

控制反转是一种以给予应用程序中目标组件更多控制为目的的设计范式，并在实际工作中起到了有效作用。

2. 依赖注入（DI）

依赖注入的英文翻译是 Dependency Injection，缩写为 DI。

依赖注入不等于控制反转！依赖注入只是实现控制反转的一种方式！ 依赖注入不等于控制反转！依赖注入只是实现控制反转的一种方式！ 依赖注入不等于控制反转！依赖注入只是实现控制反转的一种方式！

这个概念披着“高大上”的外衣，但是实质却非常单纯。用人话解释就是：不通过new() 的方式在类内部创建依赖类对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类使用。

举一个平时编码常用的一个例子，我们在Controller中调用Service服务的时候一般会这么写

@Api(tags = {"报警联系人接口"})
@RestController
@RequestMapping("/iot/contact")
public class AlarmContactController extends BaseController {
    
    // 这就是大名鼎鼎的DI啊，是不是非常简单！
    @Autowired
    private IAlarmContactService alarmContactService;

    ...

}

这就是大名鼎鼎的DI啊，是不是非常简单！

2.1 面试中被问到「依赖注入」怎么回答

依赖注入是在编译阶段尚不知道所需功能是来自哪个类的情况下，将其他对象所依赖的功能对象实例化的手段。有三种实现方式：构造器注入、setter方法注入、接口注入。

3. 依赖倒置原则（DIP）

3.1 定义

「依赖倒置」原则的英文翻译是 Dependency Inversion Principle，缩写为 DIP。中文翻译有时候也叫「依赖反转」原则。

「依赖倒置」是本文要讲述的主要内容，是七大设计原则之二，在生产实际中应用的非常广泛，主要内容为

高层模块（high-level modules）不要直接依赖低层模块（low-level）；
高层模块和低层模块应该通过抽象（abstractions）来互相依赖；
抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions）。

暂时看不懂没关系，我们先看个代码案例。

3.2 代码示例

陀螺研发了一套自动驾驶系统，在积极谈判之下和本田以及福特达成了合作协议，两个厂商各自提供汽车启动、转弯和停止的api供自动驾驶调用，系统就能实现自动驾驶，代码如下

/**
 * @author 公众号【蝉沐风】
 * @desc 福特汽车厂商提供的接口
 */
public class FordCar{
    public void run(){
        System.out.println("福特开始启动了");
    }

    public void turn(){
        System.out.println("福特开始转弯了");
    }

    public void stop(){
        System.out.println("福特开始停车了");
    }
}

/**
 * @author 公众号【蝉沐风】
 * @desc 本田汽车厂商提供的接口
 */
public class HondaCar {
    public void run() {
        System.out.println("本田开始启动了");
    }

    public void turn() {
        System.out.println("本田开始转弯了");
    }

    public void stop() {
        System.out.println("本田开始停车了");
    }
}

/**
 * @author 公众号【蝉沐风】
 * @desc 自动驾驶系统
 */
public class AutoDriver {
    public enum CarType {
        Ford, Honda
    }

    private CarType type;
    
    private HondaCar hcar = new HondaCar();
    private FordCar fcar = new FordCar();

    public AutoDriver(CarType type) {
        this.type = type;
    }

    public void runCar() {
        if (type == CarType.Ford) {
            fcar.run();
        } else {
            hcar.run();
        }
    }

    public void turnCar() {
        if (type == CarType.Ford) {
            fcar.turn();
        } else {
            hcar.turn();
        }
    }

    public void stopCar() {
        if (type == CarType.Ford) {
            fcar.stop();
        } else {
            hcar.stop();
        }
    }

}

自动驾驶系统运转良好，很快，奥迪和奔驰以及宝马纷纷找到陀螺寻求合作，陀螺不得不把代码改成这个样子。

/**
 * @author 公众号【蝉沐风】
 * @desc 自动驾驶系统
 */
public class AutoDriver {
    public enum CarType {
        Ford, Honda, Audi, Benz, Bmw
    }

    private CarType type;

    private HondaCar hcar = new HondaCar();
    private FordCar fcar = new FordCar();
    private AudiCar audicar = new AudiCar();
    private BenzCar benzcar = new BenzCar();
    private BmwCar bmwcar = new BmwCar();

    public AutoDriver(CarType type) {
        this.type = type;
    }

    public void runCar() {
        if (type == CarType.Ford) {
            fcar.run();
        } else if (type == CarType.Honda) {
            hcar.run();
        } else if (type == CarType.Audi) {
            audicar.run();
        } else if (type == CarType.Benz) {
            benzcar.run();
        } else {
            bmwcar.run();
        }
    }

    public void turnCar() {
        if (type == CarType.Ford) {
            fcar.turn();
        } else if (type == CarType.Honda) {
            hcar.turn();
        } else if (type == CarType.Audi) {
            audicar.turn();
        } else if (type == CarType.Benz) {
            benzcar.turn();
        } else {
            bmwcar.turn();
        }
    }

    public void stopCar() {
        if (type == CarType.Ford) {
            fcar.stop();
        } else if (type == CarType.Honda) {
            hcar.stop();
        } else if (type == CarType.Audi) {
            audicar.stop();
        } else if (type == CarType.Benz) {
            benzcar.stop();
        } else {
            bmwcar.stop();
        }
    }

}

如果看过我上一篇开闭原则的文章，你会马上意识到这段代码不符合开闭原则。没错，一段代码可能同时不符合多种设计原则，那针对今天的「依赖倒置」原则，这段代码问题出现在哪里呢？

我们再来看一下「依赖倒置」原则的要求：

高层模块（high-level modules）不要直接依赖低层模块（low-level）；
高层模块和低层模块应该通过抽象（abstractions）来互相依赖；
抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions）。

针对第1点，高层模块AutoDriver直接依赖了底层模块XXCar，体现就是在AutoDriver中直接new了具体的汽车对象。因此也就没有做到第2点和第3点。UML类图如下：那我们就在上层模块和低层模块之间加一层抽象吧，定义一个接口ICar，表示抽象的汽车，这样AutoDriver直接依赖的就是抽象ICar，看代码：

/**
 * @author 公众号【蝉沐风】
 * @desc 汽车的抽象接口
 */
public interface ICar {
    void run();
    void turn();
    void stop();
}

public class FordCar implements ICar{
    @Override
    public void run(){
        System.out.println("福特开始启动了");
    }
    
    @Override
    public void turn(){
        System.out.println("福特开始转弯了");
    }
    
    @Override
    public void stop(){
        System.out.println("福特开始停车了");
    }
}

public class HondaCar implements ICar{
    @Override
    public void run() {
        System.out.println("本田开始启动了");
    }

    @Override
    public void turn() {
        System.out.println("本田开始转弯了");
    }

    @Override
    public void stop() {
        System.out.println("本田开始停车了");
    }
}

public class AudiCar implements ICar{
    @Override
    public void run() {
        System.out.println("奥迪开始启动了");
    }

    @Override
    public void turn() {
        System.out.println("奥迪开始转弯了");
    }

    @Override
    public void stop() {
        System.out.println("奥迪开始停车了");
    }
}

public class BenzCar implements ICar{
    @Override
    public void run() {
        System.out.println("奔驰开始启动了");
    }

    @Override
    public void turn() {
        System.out.println("奔驰开始转弯了");
    }

    @Override
    public void stop() {
        System.out.println("奔驰开始停车了");
    }
}

public class BmwCar implements ICar {
    @Override
    public void run() {
        System.out.println("宝马开始启动了");
    }

    @Override
    public void turn() {
        System.out.println("宝马开始转弯了");
    }

    @Override
    public void stop() {
        System.out.println("宝马开始停车了");
    }
}

/**
 * @author 公众号【蝉沐风】
 * @desc 自动驾驶系统
 */
public class AutoDriver {

    private ICar car;

    public AutoDriver(ICar car) {
        this.car = car;
    }

    public void runCar() {
        car.run();
    }

    public void turnCar() {
        car.turn();
    }

    public void stopCar() {
        car.stop();
    }

}

重构之后我们发现高层模块AutoDriver直接依赖于抽象ICar，而不是直接依赖XXXCar，这样即使有更多的汽车厂家加入合作也不需要修改AutoDriver。这就是高层模块和低层模块之间通过抽象进行依赖。

此外，ICar也不依赖于XXXCar，因为ICar是高层模块定义的抽象，汽车厂家如果想达成合作，就必须遵循AutoDriver定义的标准，即需要实现ICar的接口，这就是第3条所说的具体细节依赖于抽象！

我们看一下重构之后的UML图

可以看到，原本是AutoDriver直接指向XXXCar，现在是AutoDriver直接指向抽象ICar，而各种XXXCar对象反过来指向ICar，这就是所谓的「依赖倒置（反转）」。

看到这里，不知道你是不是对「依赖倒置」原则有了深刻的理解。其实这种中间添加抽象层的思想应用非常广泛，再举两个例子。

3.3 无所不在的抽象

3.3.1 JVM的抽象

JVM虽然被称为Java虚拟机，但是其底层代码的运行并不直接依赖于Java语言，而是定义了一个字节码抽象（行业标准），只要实现字节码的标准，任何语言都可以运行在JVM之上。

3.3.2 货币的诞生

回到物物交换的时代，王二想用自己多余的鸡换一双草鞋，李四想用自己多余的草鞋换一条裤子，赵五想用自己多余的裤子换个帽子。。。如果用物物交换的方式进行下去，这个圈子可就绕到姥姥家了。然后人们就抽象出了中间层——货币，货币作为购买力的标准使得物物交换变得更加方便。

4. 推荐阅读

七大软件设计原则之一 | 开闭原则

5. 参考资料

设计模式之美【极客时间】
依赖反转原则（百度百科）
Spring IoC有什么好处（知乎）
Spring5核心原理与30个类手写实战【谭勇德】

微信关注我们

原文链接：https://my.oschina.net/u/5268560/blog/5440060

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

语义级代码克隆检测数据集的评估与改进

摘要：应用深度学习来检测语义代码克隆受到了研究界的广泛关注。本文分享自华为云社区《语义级代码克隆检测数据集的评估与改进》，作者：软件分析Lab。一、背景介绍代码克隆检测[1]是软件工程领域一个很重要的研究方向。代码克隆不必要地增加了软件系统的大小。一个系统越大，需要维护的开销就越高。为了检测和管理代码克隆，研究者把代码克隆分为四类[2]：类型一是除了注释、空格、换行之外，完全相同的代码片段；类型二是在类型一的基础上，除了类型名、变量名以及常量名之外，完全相同的代码片段；类型三是在类型二的基础上，有少量语句的增加、删除、修改；类型四是指实现的功能相同，但实现的方法完全不同。在代码克隆成为一个软件工程的研究方向以来，许多非深度学习的方法都专注在检测类型一、二、三的克隆，但是在检测语义代码克隆（中等类型三、弱类型三以及类型四）上取得的进展很有限。这是因为非深度学习的方法没有识别在词法以及语法级别实现很不相同，但属于语义代码克隆的代码对（例如冒泡排序和快速排序）。基于一个带标记的数据集（如BigCloneBench[3]），研究者提出许多基于深度学习的方法来检测语义代码克隆[...

2022-02-11

597

摘要：Kafka的API有Producer API，Consumer API还有自定义Interceptor (自定义拦截器)，以及处理的流使用的Streams API和构建连接器的Kafka Connect API。本文分享自华为云社区《【Kafka笔记】Kafka API详细解析 Java版本（Producer API，Consumer API，拦截器等）》，作者： Copy工程师。简介 Kafka的API有Producer API，Consumer API还有自定义Interceptor (自定义拦截器)，以及处理的流使用的Streams API和构建连接器的Kafka Connect API。 Producer API Kafka的Producer发送消息采用的是异步发送的方式。在消息发送过程中，涉及两个线程：main线程和Sender线程，以及一个线程共享变量RecordAccumulator。main线程将消息发送给RecordAccmulator，Sender线程不断地从RecordAccumulator中拉取消息发送给Kafka broker。这里的ACk机制，不...

2022-02-11

583

资源下载

更多资源

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。