DIの仕組みを提供するフレームワークのこと

わかいｒにくい

このノートで扱う用語はDI#60521fda198270000037706dに則る

昔はIoCコンテナと呼ばれていたらしい

newする処理を一つのコンテナ（オブジェクト、グローバル変数のようなもの）に集約するこ

fukabori.fm 48 43:30~

SingletonパターンをDIで解決した

DIは個々のclassで見たら嬉しい

しかしDIを沢山使うと、誰かが依存を作っていかないといけない

projectレベルで見ると生成知識がプロジェクト内にばらつく

Factoryで解決できるが、これでもプロジェクト上にばらついて存在してしまう

じゃあ生成知識を完全に一括管理すればよいのでは？

それがDIコンテナ

プロジェクト内の一箇所で全classの生成知識を持っている

全ての生成知識を知っているが、誰にも知られていない黒子がDIコンテナ

classの設計者や利用者はDIコンテナのことを知らなくても便利にプログラミングできる

DIコンテナはどんな感じの見た目なのか？

雑に言うとでかいMapみたいな感じ

jsならただのJSONのイメージ

keyがclass名などの任意の文字列

valueは関数とか

その関数がinstantiateする

instantiateする際に他のinstanceとかが必要になるが、それもデカJSONの別のkeyを順々に読み込んでいけば解決できる

Nix Storeと同じような依存管理だな

まだちゃんとしっくり来ていない

自作してみると理解できそう

ライブラリの説明はどうでもいい

どこを楽にする？

Clientの実装？

consturoctor内を書くのがダルい

Clientの利用？

利用する時にinstantiateしまくらないといけないのがダルい

instantiateの対象もDIしてたら、それの入れ子になる

こんな感じになる

別途設定ファイルを書く必要がある

TSライブラリはdecoratorだからまだまし #??

だからたぶん依存する内容が変わったり、新しくclass定義するときは設定ファイルも触らないといけない #??

型定義でどうにかならんのか #??

型つよOOPといえばScalaな気がするが頑張ってたりしないのかな

自作する

たぶんこれやらないとちゃんと理解出来ない

ライブラリ例

TS

type safeなDI