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