回答編集履歴
2
update
test
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
5
|
-
「コンストラクタ・インジェクション」と呼ばれるDIパターン
|
|
5
|
+
構造的には「コンストラクタ・インジェクション」と呼ばれるDIパターンにみえますね。（ただし、後述する理由によりこれらをDIとは呼べない気がしますが）
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
1
refine
test
CHANGED
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
17
|
-
円(`Circle`)オブジェクトにとって中心位置や半径という属性は、そのオブジェクトの本質をなす直接的な構成要素です。それらを外部から注入するという設計には違和感があります。また位置(`Point`,`Cordinate`)や長さ(`Length`)を表す型を導入していますが、これらは型安全性のために導入されるものであり、DIで用いるインターフェイス継承とは役割が異なっています。
|
|
17
|
+
円(`Circle`)オブジェクトにとって中心位置や半径という属性は、そのオブジェクトの本質をなす直接的な構成要素です。それらを外部から注入するという設計には違和感があります。また位置(`Point`,`Cordinate`)や長さ(`Length`)を表す型を導入していますが、これらは型安全性（単位系の区別）のために導入されるものであり、DIで用いるインターフェイス継承とは役割が異なっています。
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
@@ -22,4 +22,8 @@
|
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
|
25
|
-
関連するソフトウェア・コンポーネント(クラス)にて、あるクラスの内部実装では
|
|
25
|
+
関連するソフトウェア・コンポーネント(クラス)にて、あるクラスの内部実装では他方の **インターフェイスにのみ依存** するよう実装し、そのインターフェイスを継承/実装した **具象クラスを外部から注入する** パターンがDIだと思います。
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
こういった「**インターフェイスと実装の分離**」が不可能なクラスにはDIを適用できません（質問中の例が該当）。また、DIによりソフトウェア・コンポーネント実装同士をより疎結合にできますが、過度な疎結合アーキテクチャはメンテナンスコストが増大します。どこまでをDI適用により疎結合にするかは、対象アプリケーションが解決すべき課題次第かと思います。
|