关于golang:对控制反转和依赖注入的突然顿悟

52次阅读

共计 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 的概念。

正文完
 0