誰かがレーストラックに座っている車のパーツの束は何がいいですか？
あなたの車のクラスのすべてが車の部品を保持している場合、それは部品のウェットバッグと同じくらい便利です。
使用法
ドライバーとして私が欲しいのは私がコントロールできるものです。それは私がスピードを求めるときに反応します。それはそのレールのように処理します。それは10セントで止まることができます。
私が欲しいのは、使える車のクラスです。キャブレターがどのように機能するかを考える必要なく物事を行うために私が言うことができること。アクセルペダルについて考えてみます。それらがどのように接続されているかは私が心配することではありません。それは抽象化です。
依存性注入
依存性注入はそれとは何の関係もありません。私が車を運転しているとき、私はそれがどのように構築されたかについては考えていません。それが機能する限り、私は彼らがそれをどのように組み合わせるかを気にしません。
いいえ、DIを使用すると、ピットクルーがすぐにタイヤを交換して、コース上で雨が降り始めたときに、より良いタイヤに交換できます。完全に別の車に飛び込むことなくそれができるのは素晴らしいことです。
DIは、実際には原則に従うことです。つまり、構造と分離して使用します。
時速90マイルで新しいタイヤを取り付けることができる車はクールに聞こえるかもしれませんが、タイヤが取り付けられており、それを装着してレースに勝つことはできないと思います。
DIは、ピットクルーがパーツにアクセスできるようにパーツを取り付けることです。new同じ場所で使用して動作をプログラムすると、キャブレターを所定の位置に溶接しているようになります。確かにアセチレントーチはそれを取り除くことができますが、最初にナットとボルトの使用を検討してください。
それがDIです。確かに、newあなたがそれを欲することに気づくとすぐに何かを始めるほど簡単ではありません。代わりに、車の組み立て方法を知っている別のコードを記述する必要があります。ただし、後で変更するのが簡単になります。そして、それはあなたがあなたと一緒にトラックの周りに自動車組立工場を引きずる必要がないことを意味します。
建設
どこかで、タイヤがグッドイヤーかどうかを知る必要があります。それでは、どこに車の建設コードを置くのですか？車でない場合、ピットクルーは？いいえ、トラック？いいえ。これらすべてに動作コードがあります。レース中に実行する必要があるコード。車の組み立ては、行動コードから削除された場所でレース前に行われる必要があります。Mark Seemansは、この場所を「Composition Root」と呼んでいました。ほとんどの人はそれをメインと呼んでいます。
シンプルなパターンです。主に、オブジェクトグラフを作成してから、オブジェクトグラフ内の1つのオブジェクトに対して1つの動作メソッドを呼び出します。それでおしまい。これは、構造と動作が一緒になっている必要がある唯一の場所です。
これは、構築がすべてメインで順次配置される手続き型コードの山でなければならないという意味ではありません。言語のすべてのツールを自由に使用して作成できます。行動と混同しないでください。
これを言語で行い、DIフレームワークやIoCコンテナを使用しないことを純粋なDIと呼びます。それは非常にうまく機能します。長い間持っています。以前は、参照渡しと呼んでいました。
DIツール
DIツールが購入するのは、構造の詳細を別の言語（xml、jsonなど）に移動して、構造と動作の分離を強制することです。仲間のプログラマーが信頼newすべきではないときに使用しないと信頼できない場合は、魅力的です。
欠点は、DIツールの詳細をコードベース全体に行き渡らせたくなることです。独自仕様のアノテーションをコードベースに感染させることがある。彼らが提供する例は確かにこれを奨励しています。このツールは、ジョブをJavaプログラミングジョブとして宣伝するだけでなく、Java / Springプログラミングジョブとして宣伝するまでは、言語スペースに移動する傾向があります。
設計原則
車のロジックをプログラミングしている場合は車のクラスが必要であることは明らかだったので、長い間私は車のクラスをプログラミングしていました。しかし、DIでは、それは私にはそれほど明白ではありません。Carクラスが定義されていない場合にCarクラスを作成しないのは、DIの慣用句ですか？
抽象化について学び、クラスが必要であると判断する方法を変更していると思います。それは良い。しかし、それはDIの問題ではありません。DIは、車のクラスが必要かどうかを判断するのに役立ちません。DIは、タイヤがグッドイヤータイヤである場合に、車が気付かないようにするのに役立ちます。DIを使用すると、トラックが日本製かどうかをトラックが把握できなくなります。
ソフトウェア設計における最も基本的な質問の1つは、「何について何を知っているか」です。これが、UMLダイアグラムで示される主なものです。あなたが到達している何かを新しくするとき、それはあなたが今結びついている具体的なものへのインターフェースです。車はタイヤがグッドイヤーであることを知る必要があります。ミシュランがあなたを後援したいなら、どれがうんざりするでしょう。
これを回避することは、依存関係の逆転の原則に従って呼び出されます。正式には、（carクラスのような）高レベルモジュールは（GoodyearTireクラスのような）低レベルモジュールに直接依存すべきではありません。抽象化に依存する必要があります（Tireインターフェースなど）。
これを回避する方法は、制御の反転と呼ばれます。ここでは、制御の流れを変更することに重点が置かれています。タイヤは車を動かしますか、それとも車はタイヤを動かしますか？これを正しい方法で考えると、車とタイヤを静的に結合することができなくなります。DIは、制御の反転を追跡する1つの特定の方法です。
車のクラスが必要かどうかはわかりません。「車のロジック」をプログラミングしている場合は、どこにでも分散させるのではなく、それを保持する場所が1つあると便利です。車の構築ロジックは車の動作ロジックと同じであると考えて騙されないでください。そのため、すべて同じ場所に住む必要があります。ただし、車のロールが定義されていない場合は、どちらも必要ありません。必要に応じて、トラックの周りでオートバイをレースします。
つまり、運転用にSteeringWheelを、ピットクルー用にホイールにBoltsAndNutsを配置し、車全体を表すインスタンスがなくても、他のあらゆる種類の面白いインターフェースを配置しても問題ありませんか？
DIまたはDIなし。車全体を表すインスタンスがあれば問題ありませんが、必要がない場合、そのインスタンスは直接知りたいものではありません。車の抽象化を教えてください。使用するときに、それがガス、ディーゼル、または電気で動くかどうか気にする必要はありません。それは私がそれを構築または維持しているときに私が気にする必要がある唯一のものです。carを使用するコードがそれがどのように機能するかを知っていたり、気にする必要がない場合は、すばらしいことです。「知りません。知りたくありません。」