依存性注入を使用する理由についてリソースを探すのに苦労しています。私が見るほとんどのリソースは、オブジェクトのインスタンスをオブジェクトの別のインスタンスに渡すだけであると説明していますが、なぜですか？これはアーキテクチャ/コードをきれいにするためだけですか、それとも全体としてパフォーマンスに影響しますか？

なぜ次のことを行う必要があるのですか？

class Profile {
    public function deactivateProfile(Setting $setting)
    {
        $setting->isActive = false;
    }
}

次の代わりに？

class Profile {
    public function deactivateProfile()
    {
        $setting = new Setting();
        $setting->isActive = false;
    }
}

利点は、依存関係の注入なしで、プロファイルクラス

• Settingsオブジェクトの作成方法を知る必要があります（単一責任の原則に違反します）
• 常に同じ方法でSettingsオブジェクトを作成します（2つの間の密結合を作成します）

しかし、依存性注入では

• Settingsオブジェクトを作成するためのロジックはどこかにあります
• さまざまな種類の設定オブジェクトを簡単に使用できます

これは、この特定のケースでは無関係に思えるかもしれませんが、設定オブジェクトではなく、ファイルにデータを保存する別の実装と、データを保存する別の実装を持つDataStoreオブジェクトを考えている場合を想像してくださいデータベース。また、自動化されたテストには、模擬実装も必要です。今、あなたは本当にプロファイルクラスがそれを使用するものをハードコードすることを望まない-そしてさらに重要なことには、あなたは本当にプロファイルクラスがファイルシステムパス、DB接続、パスワードについて知りたくないので、データストアオブジェクトの作成持ってどこか別の場所に発生します。

依存性注入により、コードのテストが容易になります。

これは、MagentoのPayPalインテグレーションのキャッチしにくいバグを修正するように命じられたときに、直接体験しました。

PayPalがMagentoに支払いの失敗を通知していたときに問題が発生しました。Magentoは失敗を適切に登録しませんでした。

潜在的な修正を「手動で」テストするのは非常に面倒です。「PayPalの失敗」通知を何らかの形でトリガーする必要があります。e-checkを送信してキャンセルし、エラーが出るまで待つ必要があります。つまり、1文字のコード変更をテストするのに3日以上かかります！

幸いなことに、この関数を開発したMagentoコア開発者はテストを念頭に置いており、依存性注入パターンを使用して簡単にしたようです。これにより、次のような簡単なテストケースで作業を検証できます。

<?php
// This is the dependency we will inject to facilitate our testing
class MockHttpClient extends Varien_Http_Adapter_Curl {
    function read() {
        // Make Magento think that PayPal said "VERIFIED", no matter what they actually said...
        return "HTTP/1.1 200 OK\n\nVERIFIED";
    }
}

// Here, we trick Magento into thinking PayPal actually sent something back.
// Magento will try to verify it against PayPal's API though, and since it's fake data, it'll always fail.
$ipnPayload = array (
  'invoice'        => '100058137',         // Order ID to test against
  'txn_id'         => '04S87540L2309371A', // Test PayPal transaction ID
  'payment_status' => 'Failed'             // New payment status that Magento should ingest
);

// This is what Magento's controller calls during a normal IPN request.
// Instead of letting Magento talk to PayPal, we "inject" our fake HTTP client, which always returns VERIFIED.
Mage::getModel('paypal/ipn')->processIpnRequest($ipnPayload, new MockHttpClient());

DIパターンには他にも多くの利点があると確信していますが、テスト容易性の向上は私の最大のメリットです。

この問題の解決に興味がある場合は、GitHubリポジトリをチェックしてください：https : //github.com/bubbleupdev/BUCorefix_Paypalstatus

なぜ（問題さえ）？

なぜ依存性注入を使用する必要があるのですか？

このために私が見つけた最高のニーモニックは「new is glue」ですnew。コードで使用するたびに、そのコードはその特定の実装に結び付けられます。コンストラクターで繰り返しnewを使用すると、特定の実装のチェーンが作成されます。また、クラスのインスタンスを作成せずに「持つ」ことはできないため、そのチェーンを分離することはできません。

例として、あなたがレースカーのビデオゲームを書いていると想像してください。まず、クラスGameを作成します。クラスはを作成し、クラスRaceTrackは8 Carsを作成しMotorます。Cars異なるアクセラレーションでさらに4つ追加したい場合、多分を除いて、言及されたすべてのクラスを変更する必要がありますGame。

クリーナーコード

これは単にアーキテクチャ/コードをきれいにするためのものですか

はい。

ただし、この方法では、方法の例に過ぎないため、あまり明確ではないように思われるかもしれません。実際の利点は、複数のクラスが関係する場合にのみ示され、実証するのはより困難ですが、前の例でDIを使用すると想像してください。これらすべてを作成するコードは次のようになります。

List<Car> cars = new List<Car>();
for(int i=0; i<8; i++){
    float acceleration = 0.3f;
    float maxSpeed = 200.0f;
    Motor motor = new Motor(acceleration, maxSpeed);
    Car car = new Car(motor);
    cars.Add(car);
}
RaceTrack raceTrack = new RaceTrack(cars);
Game game = new Game(raceTrack);

これらの4つの異なる車を追加するには、次の行を追加します。

for(int i=0; i<4; i++){
    float acceleration = 0.5f;
    float maxSpeed = 100.0f;
    Motor motor = new Motor(acceleration, maxSpeed);
    Car car = new Car(motor);
    cars.Add(car);
}

• 変化いいえRaceTrack、Game、Car、またはMotor必要であった-私たちはそこに新しいバグを導入していないことが100％を確認することができますを意味しています！
• 複数のファイル間をジャンプする代わりに、画面上の完全な変更を同時に確認できます。これは、作成/セットアップ/構成を自分の責任とみなした結果です。モーターを構築するのは自動車の仕事ではありません。

パフォーマンスの考慮事項

または、これは全体としてパフォーマンスに影響しますか？

いいえ。しかし、あなたに完全に正直に言うと、そうかもしれません。

ただし、その場合でも、気にする必要がないほどばかばかしいほど少量です。将来のある時点で、5Mhz CPUと2MB RAMに相当するtamagotchiのコードを作成する必要がある場合は、これを気にする必要があるかもしれません。

99.999％*のケースでは、バグの修正に費やす時間が少なくなり、リソースを大量に使用するアルゴリズムの改善に時間がかかるため、パフォーマンスが向上します。

* 完全に構成された数

追加情報：「ハードコード」

間違えないでください、これはまだ非常に「ハードコーディング」されています-数値はコードに直接書き込まれます。ハードコードされていないということは、これらの値をテキストファイル（たとえばJSON形式）に保存し、そのファイルから値を読み取るようなものを意味します。

そのためには、ファイルを読み取り、JSONを解析するためのコードを追加する必要があります。例をもう一度検討すると、非DIバージョンでは、a Carまたはa Motorはファイルを読み取る必要があります。それは理にかなっているように聞こえません。

DIバージョンでは、ゲームを設定するコードに追加します。

私は常に依存性注入に困惑していました。Javaの領域内にのみ存在するように見えましたが、それらの領域はそれを非常に敬意をもって語っています。それは、秩序を混乱に導くと言われている偉大なパターンの1つでした。しかし、例は常に複雑で人為的であり、問​​題を特定せず、コードをより複雑にすることでそれを解決しようと試みました。

仲間のPython開発者がこの知恵を私に与えたとき、それはより理にかなった：それは単に関数に引数を渡すだけだ。まったくパターンではありません。より多くのあなたが思い出させるようなことができ、引数として何かを頼む場合でも、あなたはおそらく妥当な値を自分で提供している可能性があります。

あなたの質問は、「なぜ私の関数が引数を取るべきなのか？」とほぼ同じです そして、同じ答えがたくさんあります。つまり、発信者に決定をさせます。

もちろん、これにはコストが伴います。これは、呼び出し側に何らかの決定を強いることになり（引数をオプションにしない限り）、インターフェイスがやや複雑になるためです。その代わりに、柔軟性が得られます。

だから：この特定のSetting型/値を使用する必要がある具体的な理由はありますか？コードを呼び出すときに別のSetting型/値が必要になる理由はありますか？（テストはコードです！）

あなたが与える例は、古典的な意味での依存性注入ではありません。通常、依存性注入とは、新しく作成されたオブジェクトのフィールドに値を設定するために、オブジェクトをコンストラクターに渡すか、オブジェクトの作成直後に「セッター注入」を使用することです。

この例では、オブジェクトを引数としてインスタンスメソッドに渡します。このインスタンスメソッドは、そのオブジェクトのフィールドを変更します。依存性注入？いいえ。カプセル化とデータ隠蔽を壊しますか？絶対に！

ここで、コードが次のような場合：

class Profile {
    private $settings;

    public function __construct(Settings $settings) {
        $this->settings = $settings;
    }

    public function deactive() {
        $this->settings->isActive = false;
    }
}

次に、依存性注入を使用していると言います。注目すべき違いはSettings、コンストラクターまたはオブジェクトに渡されるProfileオブジェクトです。

これは、Settingsオブジェクトの構築が高価または複雑な場合、またはSettingsが実行時の動作を変更するために複数の具象実装が存在するインターフェイスまたは抽象クラスである場合に役立ちます。

メソッドを呼び出すのではなく、設定オブジェクトのフィールドに直接アクセスしているため、依存性注入の利点の1つであるポリモーフィズムを利用することはできません。

プロファイルの設定はそのプロファイルに固有のようです。この場合、次のいずれかを実行します。

1. Profileコンストラクター内でSettingsオブジェクトをインスタンス化します

2. コンストラクターでSettingsオブジェクトを渡し、プロファイルに適用される個々のフィールドをコピーします

正直なところ、Settingsオブジェクトを渡してから、SettingsオブジェクトdeactivateProfileの内部フィールドを変更するのはコードのにおいです。Settingsオブジェクトは、内部フィールドを変更する唯一のオブジェクトでなければなりません。

私はこのパーティーに遅れることを知っていますが、重要なポイントを見逃していると感じています。

なぜこれを行う必要があります：

class Profile {
    public function deactivateProfile(Setting $setting)
    {
        $setting->isActive = false;
    }
}

してはいけません。しかし、依存性注入が悪い考えだからではありません。これは間違っているからです。

コードを使用してこのことを見てみましょう。これを行います。

$profile = new Profile();
$profile->deactivateProfile($setting);

これから同じことを得ると：

$setting->isActive = false; // Deactivate profile

ですから、もちろん時間の無駄のようです。それはあなたがこの方法でそれをするときです。これは、依存性注入の最適な使用方法ではありません。クラスの最適な使用法でもありません。

代わりにこれがあったとしたらどうでしょう：

$profile = new Profile($setting);

$application = new Application($profile);

$application.start();

そして今でapplicationはprofile、setting実際に変化していることについて特に何も知る必要なく、を自由にアクティブ化および非アクティブ化できます。なぜそれが良いのですか？設定を変更する必要がある場合。applicationあなたはできるだけ早くあなたが何かに触れて壊し、すべてを見ることなく、安全に含まれる空間にナットを行くのは自由ですので、これらの変更から遮断壁れます。

これは、動作原理とは別の構成に従います。ここでのDIパターンは単純なものです。できる限り低いレベルで必要なものをすべて構築し、それらを配線して、1回の呼び出しですべての動作を開始します。

その結果、何が何に接続するかを決定するための別の場所と、何に何を言うかを管理するための別の場所ができます。

あなたが時間をかけて維持しなければならない何かでそれを試して、それが役に立たないかどうか見てください。

顧客として、あなたが車に何かをするためにメカニックを雇うとき、そのメカニックは最初から車を作り、それからそれを使うことを期待しますか？いいえ、整備士に作業をしてほしい車を渡します。

ガレージの所有者として、メカニックに車に何かをするように指示するとき、メカニックが自分のドライバー/レンチ/車の部品を作成することを期待していますか？いいえ、メカニックに使用する必要のあるパーツ/ツールを提供します

なぜこれを行うのですか？さて、考えてみてください。あなたはメカニックになるために誰かを雇いたいガレージオーナーです。あなたは彼らにメカニックであることを教えます（=コードを書きます）。

より簡単になるもの：

• ドライバーを使用してスポイラーを車に取り付ける方法をメカニックに教えます。
• メカニックを指導して車を作成し、スポイラーを作成し、ドライバーを作成してから、新しく作成したドライバーで、新しく作成したスポイラーを新しく作成した車に取り付けます。

メカニックにすべてをゼロから作成させないことには大きな利点があります。

• 明らかに、既存のツールとパーツをメカニックに提供するだけで、トレーニング（開発）は劇的に短縮されます。
• 同じメカニックが同じジョブを複数回実行する必要がある場合、古いドライバーを常に捨てて新しいドライバーを作成する代わりに、ドライバーがドライバーを再利用することを確認できます。
• さらに、すべてを作成することを学んだメカニックは、はるかに専門家である必要があり、したがって、より高い賃金を期待します。ここでのコーディングの例えは、多くの責任を持つクラスは、厳密に定義された単一の責任を持つクラスよりも維持がはるかに難しいということです。
• さらに、新しい発明が市場に登場し、スポイラーがプラスチックではなくカーボンで作られるようになりました。エキスパートメカニックを再訓練（=再開発）する必要があります。ただし、スポイラーを同じ方法で取り付けることができる限り、「単純な」メカニックを再訓練する必要はありません。
• 自分で作った車に依存しないメカニックがいるということは、受け取る車を処理できるメカニックがいることを意味します。メカニックのトレーニング時にまだ存在していなかった車を含む。ただし、熟練したメカニックは、トレーニング後に作成された新しい車を製造することはできません。

専門のメカニックを雇って訓練すると、費用がかかり、単純な仕事であるべきことを実行するのにより多くの時間がかかり、多くの責任のいずれかが必要なときはいつでも再訓練する必要がある従業員になります更新されます。

開発の例えでは、ハードコードされた依存関係を持つクラスを使用すると、オブジェクトの新しいバージョンSettingsが作成されるたびに継続的な再開発/変更が必要なクラスを維持するのが難しくなります。さまざまなタイプのSettingsオブジェクトを作成できるようにするには、クラスの内部ロジックを開発する必要があります。

さらに、クラスを消費する人は、クラスに渡すオブジェクトを単に渡すことができるのではなく、クラスに正しいオブジェクトの作成を要求する必要がありSettingsますSettings。これは、適切なツールを作成するようにクラスに依頼する方法を理解するための消費者向けの追加開発を意味します。

はい、依存関係の反転は、依存関係をハードコーディングするのではなく、書くのにもう少し努力します。はい、さらに入力しなければならないのは面倒です。

しかし、「変数の宣言にはより多くの労力がかかる」ため、リテラル値をハードコーディングすることを選択するのと同じ議論です。技術的には正しいのですが、プロの方が短所を数桁上回っています。

アプリケーションの最初のバージョンを作成するとき、依存関係の反転の利点はありません。依存関係の反転の利点は、その初期バージョンを変更または拡張する必要がある場合に経験されます。また、最初から正しく動作し、コードを拡張/変更する必要がないと思い込まないでください。物事を変える必要があります。

これは全体としてパフォーマンスに影響しますか？

これは、アプリケーションの実行時のパフォーマンスには影響しません。しかし、大規模な影響を与える開発時間（したがってパフォーマンス）の開発。

すべてのパターンと同様に、肥大化したデザインを避けるために「理由」を尋ねることは非常に有効です。

依存性注入については、これは間違いなく、OOP設計の最も重要な2つの側面を考えると簡単にわかります。

低結合

コンピュータープログラミングの結合：

ソフトウェアエンジニアリングでは、結合はソフトウェアモジュール間の相互依存の度合いです。2つのルーチンまたはモジュールがどれだけ密接に接続されているかの尺度。モジュール間の関係の強さ。

低結合を達成したい。強く結びついていることは、一方を変更した場合、もう一方を変更する必要がある可能性が高いことを意味します。一方のバグまたは制限は、他方のバグ/制限を引き起こす可能性があります。等々。

他のオブジェクトをインスタンス化する1つのクラスは、非常に強力な結合です。これは、他のクラスの存在を知る必要があるためです。インスタンス化する方法（コンストラクターが必要とする引数）を知る必要があり、それらの引数はコンストラクターを呼び出すときに使用できる必要があります。また、言語が明示的な分解（C ++）を必要とするかどうかに応じて、これはさらに複雑になります。新しいクラス（a NextSettingsなど）を導入する場合は、元のクラスに戻って、コンストラクターに呼び出しを追加する必要があります。

高い凝集力

凝集力：

コンピュータプログラミングでは、凝集度とは、モジュール内の要素が一緒に属する度合いを指します。

これはコインの反対側です。1つのコードユニット（1つのメソッド、1つのクラス、1つのパッケージなど）を見ると、そのユニット内のすべてのコードができるだけ少ない責任を持つようにしたいでしょう。

これの基本的な例はMVCパターンです。ドメインモデルをビュー（GUI）とそれらをつなぐコントロールレイヤーから明確に分離します。

これにより、さまざまな処理を行う大きなチャンクを取得するコードの膨張を回避できます。その一部を変更する場合は、他のすべての機能も追跡し、バグなどを回避する必要があります。そして、あなたはすぐに抜け出すのが非常に難しい穴に自分自身をプログラムします。

依存性注入では、DIを実装するクラス（または構成ファイル）に依存関係の作成または追跡を委任します。彼らはいくつかの一般的なインターフェースで作業され、そうでない意味実際の実装が何であるかは考え、持っていない-他のクラスには、正確に何が起こっているかについてはあまり気にしません責任を他のもののために。

あなたがそれらの問題を抱えているとき、彼らは解決が得意な問題を解決するためにテクニックを使うべきです。依存関係の反転と注入も同じです。

依存関係の反転またはインジェクションは、実行時に呼び出されるメソッドの実装をコードが決定できるようにする手法です。これにより、遅延バインディングの利点が最大化されます。この手法は、言語が非インスタンス関数のランタイム置換をサポートしていない場合に必要です。たとえば、Javaには、静的メソッドの呼び出しを別の実装の呼び出しに置き換えるメカニズムがありません。Pythonとは対照的に、関数呼び出しを置き換えるために必要なのは、名前を別の関数にバインドすることだけです（関数を保持する変数を再割り当てします）。

関数の実装を変更したいのはなぜですか？2つの主な理由があります。

• テスト目的で偽物を使用したい。これにより、実際にデータベースに接続することなく、データベースフェッチに依存するクラスをテストできます。
• 複数の実装をサポートする必要があります。たとえば、MySQLデータベースとPostgreSQLデータベースの両方をサポートするシステムをセットアップする必要がある場合があります。

コントロールコンテナの反転に注意することもできます。これは、この擬似コードのように見える巨大で絡み合った構築ツリーを回避するためのテクニックです。

thing5 =  new MyThing5();
thing3 = new MyThing3(thing5, new MyThing10());

myApp = new MyApp(
    new MyAppDependency1(thing5, thing3),
    new MyAppDependency2(
        new Thing1(),
        new Thing2(new Thing3(thing5, new Thing4(thing5)))
    ),
    ...
    new MyAppDependency15(thing5)
);

クラスを登録してから、構築を行います：

injector.register(Thing1); // Yes, you'd need some kind of actual class reference.
injector.register(Thing2);
...
injector.register(MyAppDepdency15);
injector.register(MyApp);

myApp = injector.create(MyApp); // The injector fills in all the construction parameters.

登録されたクラスがステートレスシングルトンになる可能性がある場合は、最も単純であることに注意してください。

注意事項

依存関係の反転は、デカップリングロジックの頼りになる答えではないことに注意してください。代わりにパラメーター化を使用する機会を探してください。たとえば、次の擬似コードメソッドを考えてみましょう。

myAverageAboveMin()
{
    dbConn = new DbConnection("my connection string");
    dbQuery = dbConn.makeQuery();
    dbQuery.Command = "SELECT * FROM MY_DATA WHERE x > :min";
    dbQuery.setParam("min", 5);
    dbQuery.Execute();
    myData = dbQuery.getAll();
    count = 0;
    total = 0;
    foreach (row in myData)
    {
        count++;
        total += row.x;
    }

    return total / count;
}

このメソッドのいくつかの部分に依存関係の反転を使用できます。

class MyQuerier
{
    private _dbConn;

    MyQueries(dbConn) { this._dbConn = dbConn; }

    fetchAboveMin(min)
    {
        dbQuery = this._dbConn.makeQuery();
        dbQuery.Command = "SELECT * FROM MY_DATA WHERE x > :min";
        dbQuery.setParam("min", min);
        dbQuery.Execute();
        return dbQuery.getAll();
    }
}


class Averager
{
    private _querier;

    Averager(querier) { this._querier = querier; }

    myAverageAboveMin(min)
    {
        myData = this._querier.fetchAboveMin(min);
        count = 0;
        total = 0;
        foreach (row in myData)
        {
            count++;
            total += row.x;
        }

        return total / count;
    }

しかし、少なくとも完全ではありません。でステートフルクラスを作成したことに注意してくださいQuerier。現在、本質的にグローバルな接続オブジェクトへの参照を保持しています。これは、プログラムの全体的な状態を理解するのが難しい、さまざまなクラスが互いにどのように連携するのかなどの問題を引き起こします。平均化ロジックをテストする場合、クエリアまたは接続を偽造することを余儀なくされていることにも注意してください。さらにより良いアプローチは、パラメータ化を増やすことです：

class MyQuerier
{
    fetchAboveMin(dbConn, min)
    {
        dbQuery = dbConn.makeQuery();
        dbQuery.Command = "SELECT * FROM MY_DATA WHERE x > :min";
        dbQuery.setParam("min", min);
        dbQuery.Execute();
        return dbQuery.getAll();
    }
}


class Averager
{
    averageData(myData)
    {
        count = 0;
        total = 0;
        foreach (row in myData)
        {
            count++;
            total += row.x;
        }

        return total / count;
    }

class StuffDoer
{
    private _querier;
    private _averager;

    StuffDoer(querier, averager)
    {
        this._querier = querier;
        this._averager = averager;
    }

    myAverageAboveMin(dbConn, min)
    {
        myData = this._querier.fetchAboveMin(dbConn, min);
        return this._averager.averageData(myData);
    }
}

接続は、操作全体を担当し、この出力をどう処理するかを知っている、さらに高いレベルで管理されます。

これで、クエリから完全に独立して平均化ロジックをテストできるようになり、さらに多くの状況でそれを使用できるようになりました。オブジェクトMyQuerierとAveragerオブジェクトが必要かどうか疑問に思うかもしれませんが、おそらく答えは、ユニットテストを行うつもりがない場合は、データベースに緊密に結合されているため、StuffDoerユニットテストStuffDoerは完全に合理的ではないということでしょう。統合テストでカバーするだけの方が理にかなっているかもしれません。その場合には、我々は細かい作りかもしれないfetchAboveMinし、averageData静的メソッドに。