控制反转和依赖注入

控制反转是通过工厂类,把实现类的方法通过其实现的接口进行调用,并通过扫描所有的@Service注解找到这些类,把他们交给spring容器管理。

依赖注入:是动态的将依赖对象注入到bean组件

单独的讲其中一个不好理解,实际使用一般是:在启动工程时,如果是非懒加载,spring容器会自动扫描特定包下面所有带@Service注解的类,然后通过@Autowire注解注入前面扫描类的实现接口,调用相应方法。

 

控制反转是一种思想,跟依赖注入其实是一个东西,只不过现有控制反转的说法,再有依赖注入。

 

*下面这个网友举的控制反转例子很形象说明了这种思想:

什么是IOC

IOC即控制反转。我们模拟一个场景,小明生在红旗下长在春风里,是咱们社会主义接班人。小明是当今社会自由恋爱的践行者,他可以选择和他喜欢的姑娘约会恋爱,父母也没权干涉(儿大不由娘啊)。但是天有不测风云,一天小明醒来发现自己穿越了(至于怎么穿越我也不知道啊),穿越到了古代,这下蛋疼了,小明的婚姻大事只能听从父母之言媒妁之约,一下子婚姻恋爱主权由自己控制转变为父母和媒人控制了。虽然例子有点荒诞,但却很好的说明了什么是控制反转。对应在编程世界,我们原先需要对象(不是女朋友啊,是Object),一般都是主动new出,这是控制正转,到spring这就不行了,你想要对象实例,ok,你必须通过请求(注解或xml配置方式)获取到对象实例,所有的实例对象由IOC容器管理。

什么是DI

 

 

DI即依赖注入。依赖注入的概念其实和控制反转本质是一样的。只是解读的维度不一样。我们用下面一张图示意一下

image.png

看到了吗?小明在古代娶媳妇儿依赖父母和媒人,而在自由恋爱的现代社会需要自己找(new)。好像这么看来自由恋爱更好吧。小伙子你还是太年轻了,自由恋爱你得花心思找个顺眼的姑娘吧,得了解她吧,得花时间和金钱追求她吧,没准时不时还给你点小脾气。但是古代就不一样了,您老就直接等着入洞房了咯(此处应有猥琐的表情),至于如何找到姑娘,如何谈判(对应的类实例就是配置属性),完全不用管,很牛叉有木有!!

 

 

 

### 控制反转(IoC)依赖注入(DI) #### 控制反转(IoC) 控制反转(Inversion of Control,简称 IoC)是指将对象的创建管理交由外部容器负责的一种设计模式。传统应用程序中,调用者通常会主动创建被调用者的实例并对其进行初始化。而在使用 IoC 的情况下,这种控制权发生了转移——不再是由调用者自己创建所需的组件,而是由一个外部容器(如 Spring 容器)来完成这些工作[^1]。 IoC 的核心在于 **“控制权的反转”**,即原本由程序代码直接操控的对象创建逻辑,现在转而由框架或容器接管。这种方式使得系统的耦合度降低,模块之间的独立性增强,从而提高了代码的灵活性可维护性[^2]。 #### 依赖注入(DI) 依赖注入(Dependency Injection,简称 DI)是实现 IoC 的具体方法之一。它指的是通过某种机制(通常是构造函数、Setter 方法或者字段注解),将所需依赖项传递给目标对象的过程。换句话说,依赖注入描述的是如何让某个类获得其所需要的服务或资源,而不是自行创建这些服务或资源[^3]。 在 Spring 框架中,依赖注入主要表现为以下几种形式: - 构造器注入:利用构造函数参数传入依赖; - Setter 注入:借助 setter 方法设置依赖关系; - 字段注入:直接标注特定注解于成员变量之上以便自动装配相应 Bean 实例[^4]。 ```java // 示例:基于构造器的依赖注入 public class UserService { private final UserRepository userRepository; public UserService(UserRepository userRepository) { // 使用构造器注入 this.userRepository = userRepository; } public void addUser(String name){ User user=new User(name); userRepository.save(user); } } ``` 以上代码片段展示了如何通过构造器向 `UserService` 类注入其依赖项 `UserRepository`。 #### 核心概念对比 | 特性 | 控制反转 (IoC) | 依赖注入 (DI) | |--------------------|---------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------| | 描述角度 | 强调谁拥有对对象生命周期及其相互间协作方式的掌控力 | 关注怎样满足某实体对其它部分的需求 | | 主要解决的问题 | 减少硬编码带来的紧耦合问题 | 明确指出哪些地方需要用到其他组件,并提供简单途径获取那些必要部件 | | 是否互斥存在 | 不完全相同但密切相关 | 是 IoC 思想下的实际操作手段 | 尽管两者经常一起提及甚至混为一谈,但实际上它们代表了不同层面的内容。可以说,DI 是达成 IoC 效果的重要工具之一[^5]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

老马识途2.0

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值