Go语言：一文看懂什么是DI依赖注入（dependency injection）设计模式

2023-03-29 更新

经过一段时间的学习与实践，针对 Golang 语言基础的 TDD 驱动开发测试训练已经告一段落，接下来会在此基础上继续使用 TDD 来构建应用程序。

博主前一部分的代码Github先贴下面👇以供参考

https://github.com/slowlydance2me/My_Golang_Study.git

前言：

本文主要介绍的是Goalng中关于 DI 的部分，前一部分会先通过典型的面向对象语言Java引入DI这个概念
仅供初学者理解使用，文章如有纰漏敬请指出
本文涉及到的知识面较为零散，其中包含面向对象编程的 SOLID原则、各语言典型的DI框架等，博主都已插入连接🔗供读者访问自行查阅
另外本文篇幅较长，粗略阅读全文大概需要5分钟，希望能在看完一遍之后对读者理解DI有所帮助，初步理解什么是依赖注入，并在实践时知道什么时候使用它

正文：

什么是DI

　　在理解它在编程中的含义之前，首先让我们了解一下它的总体含义，这可以帮助我们更好地理解这个概念。

　　依赖是指依靠某种东西来获得支持。比如我会说我们对手机的依赖程度过高。

　　在讨论依赖注入之前，我们先理解编程中的依赖是什么意思。

　　当 class A 使用 class B 的某些功能时，则表示 class A 具有 class B 依赖。

　　在 Java 中，在使用其他 class 的方法之前，我们首先需要创建那个 class 的对象（即 class A 需要创建一个 class B 实例）。

　　因此，将创建对象的任务转移给其他 class，并直接使用依赖项的过程，被称为“依赖项注入”。

　　依赖注入(Dependency Injection, DI)是一种设计模式，也是Spring框架的核心概念之一。其作用是去除Java类之间的依赖关系，实现松耦合，以便于开发测试。为了更好地理解DI，先了解DI要解决的问题。

我们先用Java代码理解一下普遍的情况：·

耦合太紧的问题

　　如果使用一个类，自然的做法是创建一个类的实例：

class Player{  
    Weapon weapon;  

    Player(){  
        // 与 Sword类紧密耦合
        this.weapon = new Sword();  

    }  

    public void attack() {
        weapon.attack();
    }
}

　　这个方法存在耦合太紧的问题，例如，玩家的武器只能是剑Sword，而不能把Sword替换成枪Gun。要把Sword改为Gun，所有涉及到的代码都要修改，当然在代码规模小的时候这根本就不是什么问题，但代码规模很大时，就会费时费力了。

依赖注入(DI)过程

　　依赖注入是一种消除类之间依赖关系的设计模式。例如，A类要依赖B类，A类不再直接创建B类，而是把这种依赖关系配置在外部xml文件（或java config文件）中，然后由Spring容器根据配置信息创建、管理bean类。

示例：

class Player{  
    Weapon weapon;  

    // weapon 被注入进来
    Player(Weapon weapon){  
        this.weapon = weapon;  

    }  

    public void attack() {
        weapon.attack();
    }

    public void setWeapon(Weapon weapon){  
        this.weapon = weapon;  
    }  
}

　　如上所示，Weapon类的实例并不在代码中创建，而是外部通过构造函数传入，传入类型是父类Weapon，所以传入的对象类型可以是任何Weapon子类。

　　传入哪个子类，可以在外部xml文件（或者java config文件）中配置，Spring容器根据配置信息创建所需子类实例，并注入Player类中，如下所示：

    <bean id="player" class="com.qikegu.demo.Player"> 
        <construct-arg ref="weapon"/>
    </bean>

    <bean id="weapon" class="com.qikegu.demo.Gun"> 
    </bean>

　　上面代码中<construct-arg ref="weapon"/> ref指向id="weapon"的bean，传入的武器类型是Gun，如果想改为Sword，可以作如下修改：

  <bean id="weapon" class="com.qikegu.demo.Sword"> 
    </bean>

　　注意：松耦合，并不是不要耦合。A类依赖B类，A类和B类之间存在紧密耦合，如果把依赖关系变为A类依赖B的父类B0类，在A类与B0类的依赖关系下，A类可使用B0类的任意子类，A类与B0类的子类之间的依赖关系是松耦合的。

　　可以看到依赖注入的技术基础是多态机制与反射机制。

有三种类型的依赖注入：

构造函数注入：依赖关系是通过 class 构造器提供的。
setter 注入：注入程序用客户端的 setter 方法注入依赖项。
接口注入：依赖项提供了一个注入方法，该方法将把依赖项注入到传递给它的任何客户端中。客户端必须实现一个接口，该接口的 setter 方法接收依赖。

依赖注入的作用是：

创建对象
知道哪些类需要那些对象
并提供所有这些对象

　　如果对象有任何更改，则依赖注入会对其进行调查，并且不应影响到使用这些对象的类。这样，如果将来对象发生变化，则依赖注入负责为类提供正确的对象。

控制反转——依赖注入背后的概念

　　这是指一个类不应静态配置其依赖项，而应由其他一些类从外部进行配置。

　　这是 S.O.L.I.D 的第五项原则——类应该依赖于抽象，而不是依赖于具体的东西（简单地说，就是硬编码）。

　　根据这些原则，一个类应该专注于履行其职责，而不是创建履行这些职责所需的对象。这就是依赖注入发挥作用的地方：它为类提供了必需的对象。

使用依赖注入的优势

帮助进行单元测试。
由于依赖关系的初始化是由注入器组件完成的，因此减少了样板代码。
扩展应用程序变得更加容易。
帮助实现松耦合，这在应用编程中很重要。

使用依赖注入的劣势

学习起来有点复杂，如果使用过度会导致管理问题和其他问题。
许多编译时错误被推送到运行时。
依赖注入框架是通过反射或动态编程实现的。这可能会妨碍 IDE 自动化的使用，例如“查找引用”，“显示调用层次结构”和安全重构。

　　你可以自己实现依赖项注入，也可以使用第三方库或框架来实现。

实现依赖注入的库和框架

Spring (Java)
Google Guice (Java)
Dagger (Java and Android)
Castle Windsor (.NET)
Unity (.NET)
Wire（Golang）

重点：Golang TDD 中理解DI

　　很对人使用Golang时对于依赖注入（dependency injection）存在诸多误解。我们希望本篇会向你展示为什么：

你不一定需要一个框架

它不会过度复杂化你的设计

它易于测试

它能让你编写优秀和通用的函数

　　就像我们在 hello-world 做的那样，我们想要编写一个问候某人的函数，只不过这次我们希望测试实际的打印（actual printing）。

　　这个函数应该长这个样子：

func Greet(name string) {
    fmt.Printf("Hello, %s", name)
}

那么我们该如何测试它呢？调用 fmt.Printf 会打印到标准输出，用测试框架来捕获它会非常困难。

我们所需要做的就是注入（这只是一个等同于「传入」的好听的词）打印的依赖。

我们的函数不需要关心在哪里打印，以及如何打印，所以我们应该接收一个接口，而非一个具体的类型。

如果我们这样做的话，就可以通过改变接口的实现，控制打印的内容，于是就能测试它了。

在实际情况中，你可以注入一些写入标准输出的内容。

如果你看看 fmt.Printf 的源码，你可以发现一种引入（hook in）的方式：

// It returns the number of bytes written and any write error encountered.
func Printf(format string, a ...interface{}) (n int, err error) {
    return Fprintf(os.Stdout, format, a...)
}

有意思！在 Printf 内部，只是传入 os.Stdout，并调用了 Fprintf。

os.Stdout 究竟是什么？Fprintf 期望第一个参数传递过来什么？

func Fprintf(w io.Writer, format string, a ...interface{}) (n int, err error) {
    p := newPrinter()
    p.doPrintf(format, a)
    n, err = w.Write(p.buf)
    p.free()
    return
}

io.Writer 是：

type Writer interface {
    Write(p []byte) (n int, err error)
}

如果你写过很多 Go 代码的话，你会发现这个接口出现的频率很高，因为 io.Writer 是一个很好的通用接口，用于「将数据放在某个地方」。

所以我们知道了，在幕后我们其实是用

Writer 来把问候发送到某处。我们现在来使用这个抽象，让我们的代码可以测试，并且重用性更好。

先写个测试

func TestGreet(t *testing.T) {
    buffer := bytes.Buffer{}
    Greet(&buffer,"Chris")

    got := buffer.String()
    want := "Hello, Chris"

    if got != want {
        t.Errorf("got '%s' want '%s'", got, want)
    }
}

bytes 包中的 buffer 类型实现了 Writer 接口。

因此，我们可以在测试中，用它来作为我们的 Writer，接着调用了 Greet后，我们可以用它来检查写入了什么。　　

尝试运行测试

./di_test.go:10:7: too many arguments in call to Greet
have (*bytes.Buffer, string)
want (string)

编写最小化代码供测试运行，并检查失败的测试输出

根据编译器提示修复问题。

func Greet(writer *bytes.Buffer, name string) {
    fmt.Printf("Hello, %s", name)
}

Hello, Chris di_test.go:16: got '' want 'Hello, Chris'

测试失败了。注意到可以打印出 name，不过它传到了标准输出

编写足够的代码使其通过

用 writer 把问候发送到我们测试中的缓冲区。记住 fmt.Fprintf 和 fmt.Printf 一样，只不过 fmt.Fprintf 会接收一个 Writer 参数，用于把字符串传递过去，而 fmt.Printf 默认是标准输出。

func Greet(writer *bytes.Buffer, name string) {
    fmt.Fprintf(writer, "Hello, %s", name)
}

现在测试就可以通过了。

重构

早些时候，编译器会告诉我们需要传入一个指向 bytes.Buffer 的指针。这在技术上是正确的，但却不是很有用。

为了展示这一点，我们把 Greet 函数接入到一个 Go 应用里面，其中我们会打印到标准输出。

func main() {
    Greet(os.Stdout, "Elodie")
}

./di.go:14:7: cannot use os.Stdout (type *os.File) as type *bytes.Buffer in argument to Greet

我们前面讨论过，fmt.Fprintf 允许传入一个 io.Writer 接口，我们知道 os.Stdout 和 bytes.Buffer 都实现了它

我们可以修改一下代码，使用更为通用的接口，这样我们现在可以在测试和应用中都使用这个函数了

package main

import (
    "fmt"
    "os"
    "io"
)

func Greet(writer io.Writer, name string) {
    fmt.Fprintf(writer, "Hello, %s", name)
}

func main() {
    Greet(os.Stdout, "Elodie")
}

关于 io.Writer 的更多内容

通过使用 io.Writer，我们还可以将数据写入哪些地方？我们的 Greet 函数的通用性怎么样了？

互联网

运行下面代码：

package main

import (
    "fmt"
    "io"
    "net/http"
)

func Greet(writer io.Writer, name string) {
    fmt.Fprintf(writer, "Hello, %s", name)
}

func MyGreeterHandler(w http.ResponseWriter, r *http.Request) {
    Greet(w, "world")
}

func main() {
    http.ListenAndServe(":5000", http.HandlerFunc(MyGreeterHandler))
}

运行程序并访问 http://localhost:5000。你会看到你的 greeting 函数被使用了。

当你编写一个 HTTP 处理器（handler）时，你需要给出 http.ResponseWriter 和用于创建请求的 http.Request。在你实现服务器时，你使用 writer 写入了请求。

你可能已经猜到，http.ResponseWriter 也实现了 io.Writer，所以我们可以重用处理器中的 Greet函数。

总结：

我们第一轮迭代的代码不易测试，因为它把数据写到了我们无法控制的地方。

通过测试的启发，我们重构了代码。因为有了注入依赖，我们可以控制数据向哪儿写入，它允许我们：

测试代码。如果你不能很轻松地测试函数，这通常是因为有依赖硬链接到了函数或全局状态。例如，如果某个服务层使用了全局的数据库连接池，这通常难以测试，并且运行速度会很慢。DI 提倡你注入一个数据库依赖（通过接口），然后就可以在测试中控制你的模拟数据了。

关注点分离，解耦了数据到达的地方和如何产生数据。如果你感觉一个方法 / 函数负责太多功能了（生成数据并且写入一个数据库？处理 HTTP 请求并且处理业务级别的逻辑），那么你可能就需要 DI 这个工具了。

在不同环境下重用代码。我们的代码所处的第一个「新」环境就是在内部进行测试。但是随后，如果其他人想要用你的代码尝试点新东西，他们只要注入他们自己的依赖就可以了。

posted @ 2023-03-27 10:00 slowlydance2me 阅读(719) 评论(0) 编辑收藏举报

刷新页面返回顶部

slowlydance2me