依赖倒置原则的理解
DIP
依赖倒置原则(Dependency Inversion Principle, DIP)：高层模块不应该依赖于低层模块，二者应该依赖于其抽象。抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
DIP 理解
- 针对接口编程，而不是针对实现编程
- 尽量不要从具体的类派生，而是以继承抽象类或实现接口来实现
- 关于高层模块与低层模块的划分可以按照决策能力的高低进行划分。业务层自然就处于上层模块，逻辑层和数据层自然归为低层。
DIP 控制反转（Inversion of Control, IoC）
反转是指：在没有使用框架之前，程序员自己控制整个程序的执行，当使用框架之后，整个程序的执行可以通过框架来控制； 框架提供了可扩展的代码骨架，用来组装对象/管理整个执行流程，程序只需关注扩展点，就可以利用框架来驱动整个程序流程的执行。
控制反转跟依赖倒置是如出一辙的两个概念，当存在依赖倒置的时候往往也存在着控制反转。但是控制反转也有自己的独特内涵。
首先我们要区分两个角色，server 和 client，也就是服务方和客户方，我们最熟悉的例子就是分布式应用的 C/S 架构，服务端和客户端。其实除此之外，C/S 关系处处可见。比如在 TCP/IP 协议栈中，我们知道，每层协议为上一层提供服务，那么这里就是一个 C/S 关系。当我们使用开发框架时，开发框架就是作为服务方，而我们自己编写的业务应用就是客户方。当 client 调用 server 时，这个叫做一般的控制；而当 server 调用 client 时，就是我们所说的控制反转，同时我们也将这个调用称为“回调”。控制反转跟依赖倒置都是一种编程思想，依赖倒置着眼于调用的形式，而控制反转则着眼于程序流程的控制权。一般来说，程序的控制权属于 client，而一旦控制权交到 server，就叫控制反转。比如你去下馆子，你是 client 餐馆是 server。你点菜，餐馆负责做菜，程序流程的控制权属于 client；而如果你去自助餐厅，程序流程的控制权就转到 server 了，也就是控制反转。
控制反转的思想体现在诸多领域。比如事件的发布/订阅就是一种控制反转，GOF设计模式中也多处体现了控制反转，比如典型的模板方法模式等。而开发框架则是控制反转思想应用的集中体现。
DIP 依赖注入（Dependency Injection, DI）
依赖注入和控制反转恰恰相反，它是一种具体的编码技巧。我们不通过 new 的方式在类内部创建依赖类的对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类来使用。
依赖注入与依赖倒置、控制反转的关系仍旧是一本万殊。依赖注入，就其广义而言，即是通过“注入”的方式，来获得依赖。我们知道，A 对象依赖于 B 对象，等价于 A 对象内部存在对 B 对象的“调用”，而前提是 A 对象内部拿到了 B 对象的引用。B 对象的引用的来源无非有以下几种：A 对象内部创建（无论是作为字段还是作为临时变量）、构造器注入、属性注入、方法注入。后面三种方式统称为“依赖注入”，而第一种方式我也生造了一个名词，称为“依赖内生”，二者根本的差异即在于，我所依赖的对象的创建工作是否由我自己来完成。当然，这个是广义的依赖注入的概念，而我们一般不会这样来使用。我们通常使用的，是依赖注入的狭义的概念。不过，直接陈述其定义可能会过于诘屈聱牙，我们还是从具体的例子来看：
Golang Demo
Demo 场景：
- 线上学校有一系列课程
- 用户可选择若干门课程进行学习
- 如果把学习课程的过程直接实现为用户的方法, 则每增加一门课程, 就需要增加一个学习方法
- 根据依赖倒置原则, 可以把学习过程抽象为学习接口, 由不同的课程实例各自实现
Bad DIP
BadUser 以不同方法实现各种课程的学习过程, 课程的增加导致BadUser代码越来越臃肿。
package dependence_inversion
import "fmt"
type BadUser struct {
iID int
sName string
}
func NewBadUser(id int, name string) *BadUser {
return &BadUser{
iID: id,
sName: name,
}
}
func (me *BadUser) StudyJavaCourse() {
fmt.Printf("%v is learning %v\n", me.sName, "java")
}
func (me *BadUser) StudyGolangCourse() {
fmt.Printf("%v is learning %v\n", me.sName, "golang")
}
Good DIP
User 抽象
GoodUser 通过实现 IUser 接口提供用户基本信息, 并把不同课程的学习过程, 委托给 ICourse 接口去实现。
package dependence_inversion
type IUser interface {
ID() int
Name() string
Study(ICourse)
}
type GoodUser struct {
iID int
sName string
}
func NewGoodUser(id int, name string) IUser {
return &GoodUser{
iID: id,
sName: name,
}
}
func (me *GoodUser) ID() int {
return me.iID
}
func (me *GoodUser) Name() string {
return me.sName
}
func (me *GoodUser) Study(course ICourse) {
course.SetUser(me)
course.Study()
}
Course 抽象
通过setter方法注入IUser, ICourse接口封装了具体课程的学习过程。
package dependence_inversion
import "fmt"
type ICourse interface {
ID() int
Name() string
SetUser(IUser)
Study()
}
type GolangCourse struct {
iID int
sName string
xCurrentUser IUser
}
func NewGolangCourse() ICourse {
return &GolangCourse{
iID: 11,
sName: "golang",
xCurrentUser: nil,
}
}
func (me *GolangCourse) ID() int {
return me.iID
}
func (me *GolangCourse) Name() string {
return me.sName
}
func (me *GolangCourse) SetUser(user IUser) {
me.xCurrentUser = user
}
func (me *GolangCourse) Study() {
fmt.Printf("%v is learning %v\n", me.xCurrentUser.Name(), me.Name())
}
Good DIP test
package main
import "testing"
import (
dip "learning/gooop/principles/dependence_inversion"
)
func TestDIP(t *testing.T) {
bu := dip.NewBadUser(1, "Tom")
bu.StudyGolangCourse()
gu := dip.NewGoodUser(2, "Mike")
gu.Study(dip.NewGolangCourse())
}
$ go test -v main/dependence_inversion_test.go
=== RUN TestDIP
Tom is learning golang
Mike is learning golang
--- PASS: TestDIP (0.00s)
PASS
ok command-line-arguments 0.002s
Public discussion