IoC 与 DI
- 1. IoC
- 2. DI
1. IoC
IoC (Inversion of Control): 控制反转
控制反转: 表示应用程序的控制权（对象的生命周期）由应用程序自身的代码反转到容器或框架中。应用程序的组件不再直接控制其依赖项的创建和生命周期管理，而是委托给容器。
Spring 就是一个具有众多工具方法的 IoC 容器。
-
没有引入 IoC 容器时，对象 A 依赖于对象 B，那么对象A在初始化或者运行到某一点的时候，自己必须主动去创建对象B或者使用已经创建的对象 B。无论是创建还是使用对象 B，控制权都在自己手上。
-
引入 IoC 容器之后，这种情形就完全改变了，对象 A 与对象 B 之间失去了直接联系，当对象 A 运行到需要对象B的时候，IoC 容器会主动创建一个对象 B 注入到对象 A 需要的地方。
通过前后的对比，我们不难看出来：对象 A 获得依赖对象 B 的过程,由主动行为变为了被动行为，控制权颠倒过来了，这就是“控制反转”这个名称的由来。
举个栗子:
- 不使用 IoC 容器.
class MessageService {
public void sendMessage(String message, String recipient) {
// 发送消息的具体实现
}
}
class NotificationService {
private MessageService messageService = new MessageService();
public void sendNotification(String message, String recipient) {
// 构造消息并发送通知
messageService.sendMessage(message, recipient);
}
}
在这段代码中, NotificationService 在内部创建了一个 MessageService 的实例，这种紧耦合会使代码难以测试和扩展。
- 使用 IoC 容器
class MessageService {
public void sendMessage(String message, String recipient) {
// 发送消息的具体实现
}
}
class NotificationService {
private MessageService messageService;
// 构造函数中接受一个 MessageService 实例
public NotificationService(MessageService messageService) {
this.messageService = messageService;
}
public void sendNotification(String message, String recipient) {
// 构造消息并发送通知
messageService.sendMessage(message, recipient);
}
}
现在，NotificationService 不再创建 MessageService 实例，而是在构造函数中接受一个 MessageService 实例。
将 MessageService 的创建、销毁、生命周期的管理全部交给框架，而我们只需要用就完了，不用关注什么时候创建、以什么样的方式创建、什么时候去销毁。
这样，就算 MessageService 的构造方法什么的变了，NotificationService 的代码也不需要怎么改动 。
使用 IoC 的好处：
- 解耦： IoC 通过将组件的依赖关系从组件自身中解耦，使得组件之间的耦合度降低，容器会负责创建和配置组件，并确保它们的依赖关系正确注入。这使得更容易替换、更新或修改组件，而无需对整个应用程序进行大规模的修改。
- 易于扩展：IoC 允许轻松地添加新的组件或替换现有的组件，而不会对应用程序的整体架构产生重大影响。这种方式使得应用程序更加灵活，易于维护和扩展。
2. DI
DI (Dependency Injection) : 依赖注⼊
所谓依赖注⼊，就是由 IoC 容器在运⾏期间，动态地将某种依赖关系注⼊到对象之中，利⽤依赖关系注⼊的⽅式，实现对象之间的解耦。
所以，依赖注⼊（DI）和控制反转（IoC）是从不同的⻆度的描述的同⼀件事情, IoC 是思想，DI 是具体的实现。
⽐如说我今天⼼情⽐较好，吃⼀顿好的犒劳犒劳⾃⼰，那么“吃⼀顿好的”是思想和⽬标（是 IoC），但最后我是吃海底捞还是杨国福？这就是具体的实现，就是 DI。
总结：
IoC 与 DI 的区别就是 IoC 是一种思想，DI 是具体的实现。
好啦！ 以上就是对 IoC 与 DI 的讲解，希望能帮到你 ！
评论区欢迎指正 !
