依存性逆転の法則
（Javaなどで）具象クラスA,BがあってAの中でBを使った"操作"をしている（A->Bの方向で依存している）とき、その”操作”を表すインタフェースFooを設けて、A -> Foo <- Bのような依存関係する。
je6bmq.iconA -> FooとB -> Fooの方向が逆になることに起因するという理解。ただし、ここで B->Fooは同じ依存でもFooを実装する関係にあるので、A-> FooとB -> Fooは少し意味が違う
これにより、
Bを同じインタフェースを実装しているCに差し替えられる
テスト用のMockを注入できる
Bに変更があったときに、ビルド対象はBだけでよい
je6bmq.icon
RustでMockを差し込もうと思うと結局Traitとそのimplを分ける必要があって、勝手にDIPに則った状態になる、というのは好きな表現
何でもかんでもインタフェースを間に挟もう、というのは必要ないと思うが、具象クラスの依存関係が1段浅いところに現れる。そのため、例えばAPIをたたくのに使うプロトコルはアプリケーションの成長に伴って変え得る（HTTP, gRPC, GraphQL?）上、汎用的になりやすいのでインタフェースを切っては、と思うけど、一方、ビジネスロジックとかはインタフェースを決めるほど抽象化が効かなそうな直感があるので、そこは別にいいんじゃない？みたいな感覚
結局後から具象を注入したいときに注入しやすいように関数だったり状態をシンプルにしておく、がすべてみたいな節ない？
avashe.icon依存性逆転とかいう名付けわかりづらい
単なるインターフェースの切り分け、動的ないし静的なディスパッチ