超便利！追加のコードを書かずに依存性注入の5つの原則をマスターする

この概念に初めて遭遇した場合、一瞬理解できないかもしれません。インターネット上のさまざまな説明により、さらに混乱し、それほど単純ではないと感じるかもしれません。実際、依存性注入自体は純粋かつ単純です。

[[287085]]

簡単に言えば、依存性注入とは、注入されるものと注入する側との間に関連性を確立する方法、手段、または手段です。

依存性注入の目的は疎結合、つまり相互作用するオブジェクト間の疎結合です。

今日、Xiaoxin は依存性注入 (DI) の 5 つの原則を中心に説明した、非常に実用的な記事を紹介します。

これら 5 つの基本的な考え方に従うことで、DI を実行するときに余分な時間をかけてコードを記述する必要がなくなり、非常に便利になります。

5つの基本原則

1. コンストラクタをシンプルに保つ

コンストラクターはシンプルに保つ必要があります。クラスのコンストラクターは、null のチェック、作成可能なクラスの作成、後で使用するために依存関係を保存する以外の作業を行うべきではありません。

コーディングロジックを含めないでください。クラス コンストラクターに null をチェックする if 句がない場合、クラスは 2 つのクラスに分割されます。 (nil 値のパラメータをチェックする if 文を使わずにこれを行う方法もあります。)

複雑なコンストラクターは、クラスが過剰な作業を行っていることを示しています。コンストラクターは短く、シンプルに、ロジックなしで維持します。

2. インターフェースは抽象的だと思い込まない

インターフェースは素晴らしく、絶賛せずにはいられません。ただし、すべてのインターフェースが抽象的であるとは限らないことを認識することが重要です。

たとえば、インターフェースがパブリック部分クラスの正確な表現である場合、実際には何も抽象化されませんよね? (これらのインターフェースは、C++ ヘッダー ファイルと同様に、ヘッダー インターフェースと呼ばれます)。クラスから抽出されたインターフェースは、そのクラスのみに密結合される可能性が高く、インターフェースが抽象クラスとして役に立たなくなることがあります。

最後に、抽象クラスは漏洩する可能性があります。つまり、実装クラスに関する特定の詳細が明らかになる可能性があります。リークのある抽象クラスも通常は特定の実装クラスに関連付けられています。

3. 実装クラスについて仮定をしない

もちろん、実装クラスがなければインターフェースは役に立ちません。ただし、開発者としては実装クラスについて何らかの仮定を立てるべきではありません。

インターフェースによって生成された契約に従ってのみコードを記述する必要があります。実装を記述したとしても、実装について考えずにインターフェースに対してコードを記述すべきではありません。言い換えると、インターフェースに対するコードは、インターフェースの新しい、より優れた実装のように動作します。

適切に設計されたインターフェースは、何をすべきか、どのように使用するかを伝えます。このインターフェースの実装は、インターフェースの使用とは無関係です。

4. 実装クラスではなく抽象クラスのコード

このフレーズは、「Gang of Four」の 1 人である Erich Gamma (『Design Patterns』の著者) が考案したもので、重要な考え方です。新しい開発者に教えることができることが 1 つだけあるとしたら、それはこのモットーです。

抽象クラスは柔軟性があります。通常はインターフェースですが、常にそうであるとは限りません (以下を参照)。

インターフェース (または抽象クラス) はさまざまな方法で実装できます。実装が完了する前にインターフェースをコーディングできます。実装をコーディングすると、密結合された柔軟性のないシステムが作成されます。単一の実装に限定しないでください。代わりに、抽象化を使用して、拡張可能、再利用可能、柔軟なコードを記述します。

5. 作るべきでないものを作らない

クラスは単一責任の原則に従う必要があります。つまり、クラスは 1 つのことだけを実行する必要があります。

この場合、これ以上のものを作成する必要はありません。そうしないと、2 つのことが実行されます。代わりに、必要な機能に基づいて機能を作成し、提供する必要があります。

作成可能なクラスと注入可能なクラス

では、何を作成すればよいのでしょうか?

私たちが考慮する必要があるオブジェクトには、作成可能なクラスと注入可能なクラスの 2 種類があります。

作成可能なクラスは、継続的に作成されるクラスです。共通のランタイム クラスまたはユーティリティ クラスです。

通常、ランタイム内のクラスは作成可能なクラスと見なされます。これらのクラスは挿入するのではなく、作成する必要があります。これらは短命であり、通常は 1 つのメソッドの範囲を超えることはありません。作成可能なクラスはすべてのクラスに必須であり、コンストラクターで作成できます。作成可能なクラスは、そのコンストラクターに別のクラスを渡すことしかできません。

一方、注入可能なクラスは、直接作成したくないクラスです。また、依存関係をハードコードしたくないクラスは、常に DI を介して渡す必要があります。

コンストラクターでは、通常は依存関係として指定されます。上記のルールによれば、注入可能なクラスはインスタンスではなくインターフェースによって注入されたクラスに依存する必要があります。

通常はビジネスロジックとして記述されたクラスです。抽象クラス (通常はインターフェース) の背後に隠されています。また、注入可能なクラスはコンストラクター内で他の注入可能なクラスを要求できることにも注意してください。

DI を適切に使用すると、コードに大きな影響を与える可能性があります。これをうまく行うことは難しくありませんが、先見性、計画性、設計が必要です。

ただし、コードを保守するときには、少しの作業で大きな成果が得られます。疎結合のコードを修正することは、メンテナーの夢です。私たちはそのようなコードを書くために一生懸命努力し、後で報われると信じるべきです。