📗 なぜ依存を注入するのか DIの原理・原則とパターンを読んだ感想 | Happy developing

なぜ依存を注入するのか DIの原理・原則とパターン 著者: Steven van Deursen, Mark Seemann 訳者: 須田智之 表紙には.NETやC#の文字はないのですが、前の版は"Dependency Injection in .NET"で.NETを前提した本のようでした。 ただ、はじめにで 本書では、.NETとC#を用いて、依存注入に関する用語や指針を包括的に紹介し、描写しているのですが、本書の価値が.NETの外の世界にも届くことを望んでいます。 とありました。 RustのDIでなにか活かせる教えを期待して、読んでみました。 第1部 依存注入 (Dependency Injection: DI) の役割第1章 依存注入 (Dependency Injection: DI) の基本: 依存注入とは何なのか? なぜ使うのか? どのように使うのか?まず、保守容易性(maint

[strawberryhunter]

SpringFrameworkで何度循環参照に無駄な時間を費やしてきたことか。DIフレームワークは無用の長物だが、考え方は有用というのが個人的な結論。主にDB接続以外はDIしないようにしている。

[izoc]

DIコンテナを使う使わないは置いといて、依存性の注入って考え方はシステム設計ですごい大事だと思う

[kagerouttepaso]

DIは使いやすく優秀なDIコンテナあって初めて嬉しい技術

[tokuniimihanai]

DIの文脈で「依存性」という誤訳を使ってないのが良いね。依存しているものを注入してるのであって何らかの性質を注入したいわけではないからね

[seal2501]

DIしてないコードは特にテストコードのメンテがしんどい。比較的PythonはDIじゃなくてもテスト書きやすいけど構造変更にナイーブなテストコードになり辛い。Jestは黒魔術感がすごいのでJS/TSもできればDIで書きたい

[uchiten]

“依存注入を行うと、何がどれを呼び出しているかをすぐに把握できないという問題点があります。” これが大きい。

[t-murachi]

Dependency injection自体はそこまで真新しい概念ではなくて、例えばシングルトンが欲しくなるようなシチュエーションで、呼び出し側がそのオブジェクトを用意し提供できるようにするベターな手法だったりする。

[versatile]

なんでも DI にしていくと、cyclic になってしまってどっかでちゃんと new しなきゃならなくなるのはきっと設計が悪いんだろうな・・・。java つかってると Spring つかうことになるから DI は必須

[PJ_purejam]

Dependency injection 依存注入　はじめてきいた単語だ。従属挿入くらいでいいのでは？

[Iridium]

C的な頭で言うと、ポインタのポインタ渡しの進化版みたいなものだっけ？でも「依存の注入」って普段の生活で言われたらなんか別なものを想像する。麻薬とか

[ducky19999]

“揮発性依存とは、外部のDBのように動かすには別の設定が必要になるものや、非決定的(ランダム、現在時刻)なもの”

[brightsoda]

依存しんご

[xenon_abe]

やむを得ない循環参照はある。DIフレームワークに循環参照を解決する仕組みはあるはずなので、無理に設計し直すより循環参照を許容した方が良い。

[toro-chan]

DIを蔓延させると、処理が細切れ過ぎてどこが何をしてるかさっぱり分からなくなる。この記事ではmainの近くに依存性を明記するというがフレームワークにmainはないのでは。結局よくわからなくなる気がする

[prograti]

オブジェクトを生成するための便利ツールみたいな使われ方をしてるプロジェクトが多いけど、文中で触れられている「依存性逆転の原則」の理解が大事ですよね

[mak_in]

DIってオブジェクトに対して単純にそのまま使うシチュエーションから一歩踏み込んで色々やりたい時に便利。生存期間を調整したい(常時1つ/処理ごと)、使う場所で設定を共通に、テスト用に一時的に振る舞いを変える…等