共计 1110 个字符，预计需要花费 3 分钟才能阅读完成。
管制反转和依赖注入的概念在网络上有大量的解释，很多都十分的具体，但对我来说过多的解释，容易把我绕来绕去，昨天听大佬的课，忽然清晰地顿悟了。心愿通过简略的形容，记录我的了解。
管制反转（IOC）：
上面通过两张简略的图，理解一下管制反转的思维，咱们假如本人当初想吃回锅肉！
首先，咱们能够本人炒一道合乎本人口味的回锅肉，能够多加肉！而后咱们就把它吃掉！！这种状况下 回锅肉炒成什么样由咱们本人管制。
ok！第二天咱们又想吃回锅肉了，然而有点懒，咱们抉择点外卖。
这回咱们叫的外卖，那么商家将回锅肉炒成什么样并不是咱们能决定的，也就是回锅肉炒成什么样不是咱们可能管制的，咱们就是拿到外卖吃。
很显著回锅肉的控制权从本人变成了他人，这种就叫做管制反转。
在面向对象编程中，每当咱们要 new 一个新的对象的时候，也就是咱们所说的实例化对象，个别状况下都是被动 new 一个新的对象。在 IOC 思维中，咱们通常把实例化的工作交给他人，也就是本人被动的实例化变为被动的实例化，本人对实例的控制权被他人代替了，即控制权反转了。咱们个别将实例化的工作交给 IOC 容器对立治理生命周期。
依赖注入（DI）：
依赖注入是 实现管制反转思维的一种形式，其想法就是在对象或属性被初始化的时候，将它所须要的依赖从内部注入进来，并不需要本人外部实例化依赖。
咱们通过一段代码（Go 语言）来看看为什么注入的依赖合乎管制反转的思维。
type Player struct {name string}
type GameRoom struct {player *Player}
// 这里咱们就将 GameRoom 依赖的 Player 从内部注入进来
//Player 的实例化也交给了内部，所以对于 Player 的控制权反转了。func NewGameRoom(player *Player) *GameRoom {return &GameRoom{player: player}
}很多状况下咱们会 应用接口注入 ，而接口的实例化就归内部（通常是 IOC 容器），不仅合乎多态，更加体现了 依赖倒置准则（单方都应该依赖一个形象）。
type Player interface {GetName() string
}
type GameRoom struct {player Player}
//Player 通过接口的形式注入进来，咱们毋庸
// 关系 Player 如何实现的，这样连注入的依赖
// 也变成形象的
func NewGameRoom(player Player) *GameRoom {return &GameRoom{player: player}
}这种形式益处颇多，比方更容易被单元测试、代码耦合性升高等等等等。心愿这篇最简略的解释，可能使咱们更快地了解 IOC 和 DI 的概念。