おさらいDIについて社内で理解してもらう機会があったのでここで簡単におさらい。簡単な学生の試験の点数を評価してくれるインターフェイスと実装クラスを例に説明します。}}ACheckPointLogicImplは、100点以外は悪い評価とかなり厳しい評価基準です。BCheckPointLogicImplを作りました。}}BCheckPointLogicImplは、かなり現実的な評価基準に変わりました。ここで注意するのは評価ロジックを使っているSampleクラスのほうです。前のものと比べてどうでしょうか?そうです。インターフェイスを変えずに実装クラスだけを差し替えました。今回のアプリではBCheckPointLogicImplが採用されることになりましたが、あるケースによってはACheckPointLogicImplを使う場合も出てくるかと思います。その場合はCheckPointLogicFactoryクラスなるものを作って対応することになるかと思いますが、ファクトリの中ではACheckPointLogicImpl、BCheckPointLogicImplをnewするコードはどうしても密に結合することになってしまいます。この密結合をDIコンテナを使って疎結合に変えてみましょう。</component></components>Sampleクラスを見るとどこにも実装クラスをnewしているコードがありません。これで依存関係は切れている状態になります。(でも、DIコンテナには依存しとるやんけ!という突っ込みはありますが、これも極力container.getComponentしない方法も可能です。これは後に説明します。(CheckPointLogic)container.getComponent("checkPointLogic");実際この部分でどのクラスのインスタンスが生成されるかは、上記のapp.diconで決まります。対応するクラスは、BCheckPointLogicImplクラスであると設定されていますので、実際にはBCheckPointLogicImplクラスのインスタンスがDIコンテナ経由で返されます。ある日突然上司から言われてロジックを変えなくてはならなくなった場合は、app.diconのBCheckPointLogicImplをACheckPointLogicImplに変えるだけで修正範囲を最小限にできます。Sampleクラスの変更は不要です。開発中は各クラスの依存関係をインターフェイスによって分離して実装クラスをnewするコードも排除。実行時にはクラス間の依存関係をアプリケーション外部から注入するというイメージなります。外から依存関係を注入するからDIなんですね。DIでは、インターフェイスだけ知っていればよくあとの実装クラスはDIの設定に応じてDIコンテナが自動的に引き合わせてくれます。DIによってテストしやすくなるといろいろメリットありますが、動的にアプリケーションの構成を変えれるのは大きなメリットだと思います。標準品を作っても特定顧客向けのコードを織り込んだりしているうちにスパゲッチになったという話はよく聞きます。最初から見えない顧客を想定しても仕方なので、そういうときはその顧客の仕様が決まった時点で顧客用の実装クラスを作ってインジェクしてあげればよいのではないかと思います。この際に、変更・追加が必要なのは顧客用実装クラスとDIの設定ファイルだけです。基幹部分のコードは変更の必要がなくなります。説明することがあるのですが、まずは第一弾、ご参考までに。Sourcingを学ぶための教材ServiceとDCIについて月別アーカイブはてなブログをはじめよう!j5ik2oさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。