ほぼwireの紹介

1. 1
wireというDIツールをプロダクトで使ってみた

2. 2
● メイン所属：信州大学工学部4年
● サブ所属：メルペイ(インターン)
● ポジション：バックエンド
● 趣味：カメラ、筋トレ
田村 弘(@bieshan)

3. 3
wireとは何か
今日は何を話すか
wireの仕組み
wireをプロダクトに入れてみた
wireの難しいところ
02
03
04
01

4. 4
wireとは何か
● DI(Dependency injection(依存性の注入))
○ 簡単に必要な依存関係を注入してくれる
● DIツールは何か
○ 依存関係をごにょごにょして楽にしてくれるツール
● wireの場合
○ 依存関係のコードを生成してくれる

5. 5
wireとは何か
● DI(Dependency injection(依存性の注入))
○ 簡単に必要な依存関係を注入してくれる
● DIツールは何か
○ 依存関係をごにょごにょして楽にしてくれるツール
● あると何が嬉しいのか
○ 依存関係用のコードを減らすことができる
○ 依存関係が明白になる

6. 6
wireとは何か
● GoのDIツールには二種類ある
○ runtimeに依存を解決するもの
○ コンパイル時に依存を解決するもの
● wireはコンパイル時で、要はコードを生成してくれる

7. 7
wireの仕組み(雰囲気)
NewXX(*DB, *Logger) *Service
NewDB() *DB
NewLogger() *Logger
Serviceを返すメ
ソッドが欲しい
Serviceを返すメソッド
依存されるメソッド達
了解

8. 8
wireの仕組み(雰囲気)

9. 9
wireの仕組み(雰囲気)

10. 10
wireの仕組み(雰囲気)

11. 11
wireをプロダクトに導入してみた
● プロダクトというと
○ 基本的にloggerとかDBとか複数の依存先を持つ
○ 特にテストだと場合分けが多く、同じ生成コードが繰り返される
func Test(t *testing) {
requiredService1 := FakeService1()
requiredService2 := FakeService2()
.
.
.
TestService := NewTestService(
requiredService1,
requiredService2,
.
.
.
)
// 略
}

12. 12
wireをプロダクトに導入してみた
● プロダクトというと
○ 基本的にloggerとかDBとか複数の依存先を持つ
○ 特にテストだと場合分けが多く、同じ生成コードが繰り返される
func TestServiceSuccess(t *testing) {
requiredService1 := FakeService1()
requiredService2 := FakeService2()
requiredService3 := FakeService3()
TestService := NewTestService(
requiredService1,
requiredService2,
requiredService3,
)
assert.True(t, TestService.run())
}
requiredService1 := FakeService1()
requiredService2 := FakeService2()
ここの部分コードをwireで生成する

13. 13
wireをプロダクトに導入してみた
func InitTestService() *Service {
wire.Build(
FakeService1,
FakeService2,
FakeService3,
FakeService4,
NewTestService,
)
return nil
}
Wireを使って
コードを生成
func InitTestService() *Service {
FakeService1 := FakeService1()
FakeService2 := FakeService2()
FakeService3 := FakeService3()
FakeService4 := FakeService4()
service := NewTestService(
requiredService1,
requiredService2,
requiredService3,
requiredService4,
)
return service
}

14. 14
wireをプロダクトに導入してみた
func Test(t *testing) {
requiredService1 := FakeService1()
requiredService2 := FakeService2()
.
.
.
TestService := NewTestService(
requiredService1,
requiredService2,
.
.
.
)
// 略
}
func Test(t *testing) {
testService := InitTest()
// 略
}こうなる

15. 15
wireの難しいところ
NewXX(*DB, *DB) *Service
NewFooDB() *DB
NewBarDB() *DB
どっち？
Serviceを返すメソッド
依存されるメソッド達

16. 16
wireの難しいところ
新しい型を作ればいい
type MySQLConnectionString string

17. 17
wireの難しいところ
func NewMySQLConn() string {}
func NewMySQLConn() MySQLConnectionString {}
書き換えないといけない

18. 18
wireの難しいところ
全部が全部それができるわけではない...

19. 19
wireの難しいところ
例えば、外部ライブラリーのメソッドを使う場合
fooDb := mySQL.NewConn()
barDb := mySQL.NewConn()
hogeService := NewService(fooDb, barDb)
型を区別するため新しい型を作りたいが....

20. 20
wireの難しいところ
func NewConn() *Conn {}
ライブラリー内部
ライブラリー内部まで書き換えられない...

21. 21
wireの難しいところ
なので、
type HogeDBConn struct {
Conn *mySQL.Conn
}
構造体でラップをして使う

22. 22
まとめ
● いいところ
○ 依存性の注入が楽になる
○ 依存関係が明白
○ コードが綺麗になる
● 難しいところ
○ 書くコードに制限がかかる

23. 23
ご清聴ありがとうございました。