【转】Is there a better dependency injection pattern in golang?
https://coolshell.cn/articles/9949.html
https://dotblogs.com.tw/daniel/2018/01/17/140435
https://github.com/golobby/container
https://blog.drewolson.org/dependency-injection-in-go
https://quii.gitbook.io/learn-go-with-tests/go-fundamentals/mocking
---------------------
案例解釋：
小明是個愛乾淨的人，但他工作時常加班導致房間雜亂，他不能忍受此狀況，所以小明去找一個清潔阿姨每天幫忙他打掃家裡
哪天阿姨哪天有事不能打掃，小明就必須要再去找人來幫忙打掃，由此可知小明耦合阿姨
------------------------------------------------------------------------------------
如果今天是....
小明把他要的條件給「打掃仲介公司」，仲介公司幫他尋找有沒有符合小明需求的打掃阿姨，假如今天A阿姨請假了，仲介公司會自動找另一個符合需求B阿姨幫忙打掃...
原本小明需耦合於打掃阿姨，現在被「仲介公司」做了控制反轉讓「仲介公司」來提供打掃阿姨。
小明不用管是否今天有人會來打掃，「仲介公司」會幫小明找到一個掃地阿姨。
「仲介公司」可看作 依賴注入容器
「小明」可看作 被動接收物件
「打掃阿姨」可看作 被依賴物件
在使用IOC容器前需先了解雙方的依賴關係(誰依賴誰?)
上述還有一個很重要的觀念是，依賴和被接收對象要倚賴抽象。
範例使用：VS2015
IOC容器：AutoFac
下面範例來說明上面的例子
小明自己依賴於掃地阿姨
依賴程式碼寫在小明類別內部日後要更改只能動內部程式碼。
/// <summary>
/// 小明直接依賴 Aunt 不是依賴抽象
/// 日後要改必須動內部
/// </summary>
public class Mine
{
public Aunt aunt = new Aunt();
public void Room()
{
aunt.Swapping();
}
}
呼叫使用時
Mine mine = new Mine();
mine.Room();
小明找仲介公司
仲介公司(Ioc容器)
在仲介公司內註冊需求，讓仲介公司日後幫你找人（註冊的類別）
/// <summary>
/// 仲介公司
/// </summary>
/// <returns></returns>
private static IContainer MiddleCompany()
{
ContainerBuilder builder = new ContainerBuilder();
//在仲介公司裡寫需求人申請單
builder.RegisterType<MineWithMiddle>();
//小明所需打掃阿姨需求
builder.RegisterType<Aunt>().As<ISwapable>();
return builder.Build();
}
使用起來
IContainer middleCompany = MiddleCompany();
//仲介公司(IOC AutoFac)自動幫小明注入一個打掃阿姨
MineWithMiddle mineWithMiddle = middleCompany.Resolve<MineWithMiddle>();
mineWithMiddle.Room();
總結：
- 系統中模組建議依賴抽象，因為各個模組間不需要知道對方太多細節（實作），知道越多耦合越強。
像網頁瀏覽器和伺服器是依賴Http協議，用戶端不管是手機.電腦,平板，伺服器端php,asp.net,java都可互相交信，依賴Http協議共用的合約 - 控制反轉：是一個設計思想 ，把對於某個物件的控制權移轉給共同第三方
- 依賴注入：把被依賴物件注入被動接收物件中
範例原始碼 ：https://github.com/isdaniel/IOC_Sample
參考連結 : http://www.cnblogs.com/xdp-gacl/p/4249939.html
----------------------
-------
Given this code:
package main
import (
"fmt"
)
type datstr string
type Guy interface {
SomeDumbGuy() string
}
func (d *datstr) SomeDumbGuy() string {
return "some guy"
}
func someConsumer(g Guy) {
fmt.Println("Hello, " + g.SomeDumbGuy())
}
func main() {
var d datstr
someConsumer(&d)
}
Is the wiring of components together that's done in main the right way to wire a dependency together? It seems like I'm over using this a bit in my code. Is there a common pattern better than this, or am I overthinking it?
datastrtype that returns aGuyinterface, as this gives a compile-time guarantee that your structure fulfills the interface it is expected to fulfill.The best practice is not to use a DI library. Go is meant to be a simple language that is easy to follow. A DI library/framework will abstract that away from you (and to some extent make DI magical).
Google's Wire looks promising. There're some articles about it:
Compile-time Dependency Injection With Go Cloud's Wire
Go Dependency Injection with Wire
Uber's Dig is pretty awesome. Here's a great blog post about it: Dependency Injection in Go
--------------------------------------------------------------------------------