まじめにgoでDIを考える前のメモ
そろそろDIについてもまじめに考える必要が出てきたので考えることにする（この記事では終わらない）。たまには答えになっていないようなメモでも。
何となく最近思うのは、goゆえの制約はあっても、goだからで省略できる特別なことは特に無いなということ（省略できるかどうかは書こうとしてるものの領域に依存してる）。
あと、アプリケーションのコードが書ける人と、ライブラリのコードが書ける人と、設計をやる人はいても、ライブラリを上手くアプリケーション側に統合できる人は少ないのかもしれないというようなこと。
いつDIを気にしたくなるか
いつDIを気にしたくなるかあるいはどういう状態なら必ずどうしてもDIのことを考える必要が出てくるかについてもメモしておきたい。DIを本気で考える必要があるというタイミングは個人的には以下かなと想った。
依存の依存が共有されたとき
前提として設定による分岐と文脈による分岐が分離できている必要がある。そして設定の分岐による生成が面倒というところで片足DIに踏み込む。特にconfigとコンポーネント（ないしはその依存ライブラリ）との結びつきがめんどうという話と複数のバイナリを相手にしたくなったとき。
ここまではまだどうにか無くても頑張っていけるが依存の依存が共有されたときが無理。
依存の依存が共有されたとき
図示すると以下の様な形。AはXからもYからも依存されている。
A -> X A -> Y
ここで、例えば以下の様なXやYのファクトリー関数をいちいち変更するのが大変という状況で
x/New :: A -> something* -> x/X y/New :: A -> something* -> y/Y
設定からX,Yを作る関数を定義するだけでは避けられないとき
XFromConfig :: conf -> x/X YFromConfig :: conf -> y/Y // 内部的にAを共有したい
（その他登録するコンポーネントはファクトリーであるべきだとか細々とした実装依存はある）
ところでなぜ設定からX,Yを作る関数を定義したくなるかというとXやYの依存が時折変わるから。その際に数十のmain.goを書き換えて回るのは不毛。
どう対応するつもりか
wireとかを調べたのだけれど、なるべく段階的に移行したかったり、なるべく特殊なコマンドの実行が必須になることは後々に遅延したい。
対応予定の方針
個人的には以下のような方針で対応することを考えている。
- sharedなパッケージを作りここでコンポーネントを作成
- registry的なオブジェクトに登録する
- ただし、そのままだと全ての依存が全てのバイナリの依存になるので直接は使わないようにbuild
ここで特別なコマンドが必須になりそうでそれなら既存の何かを上手に使った方が良いのではという気持ちになっている。
制約
ただし以下の様なことも気にしたいと思っている（制約）。
- main.goひとつだけを指定してgo runで動かせることは死守したい
- main.go内のコードが太るのは悪
- ビルドタグで分岐という形で持っていくと楽だけれどビルドシステム必須ということはなるべく避けたい
間違いなさそうだなと思っているのは、個々のバイナリでの不要な依存を断ち切るにはコード生成（コード出力）が必須だということ。一方で依存最小を考えすぎるのはもはやロートル的な思考という感じもしなくもない（機械学習系の何かとかはそのまま入れるとひどいことになるし(goとは無関係)）。
misc的なこと
misc的なメモを。まずDIコンテナとかは実装の詳細の話な気がするので依存管理の本質ではないような感覚がある。とはいえ手軽ななにかで済ませられるなら済ませたい。
あとこの辺のパッケージは調べてみたりした。
例えばwireなどをまじめに使っている人などの話を聞いてみたりしたい。(一応触ったことはあるしこれらについて意見は持っているものの)。
