編集履歴

回答編集履歴

文章の表現変更

2018/05/16 19:10

投稿

スコア804

test CHANGED Viewed

@@ -22,7 +22,7 @@
 **DIを使うことのメリットについて**
-DIは、その仕組み上、インターフェイスとデフォルトコンストラクタを求めます。これによってクラスのカプセル化はより高度化されること結果となりました。これにより、想定外のパラメータの発生リスクが最小化され、AもBもより堅牢なプログラムとなりました。アノテーションによる定義は、設定ファイルの定義からの解放を促し、人の作業によるバグの発生の可能性の低減に寄与しています。
+DIは、その仕組み上、インターフェイスとデフォルトコンストラクタを求めます。これによってクラスのカプセル化はより高度化されること結果となりました。想定外のパラメータの発生リスクが最小化され、よりシンプルにロジックの実装のみ記載可能となり、バグ発生の確率低減にも寄与します。さらにアノテーションによる定義により、設定ファイルの定義からの解放を促し、こちらもまたバグの発生確率の低減に繋がっています。

段落修正

2018/05/16 19:10

投稿

Hiroshi-Aoki

スコア804

test CHANGED Viewed

@@ -12,9 +12,7 @@
 **「BができるまでAのテストができない」について**
-Aをテストするにあたり、Bをモックにするとします。
-BはモックであってBではなく、BはBで作成している最中なので同じクラス名を使うことができません。この時BのモックはBMockのような名前だったり、パッケージを変える形でテストをすることになります。結果、Aはテスト用のソースコードになります。
+Aをテストするにあたり、Bをモックにするとします。BはモックであってBではなく、BはBで作成している最中なので同じクラス名を使うことができません。この時BのモックはBMockのような名前だったり、パッケージを変える形でテストをすることになります。結果、Aはテスト用のソースコードになります。
 一見問題なさそうに思いますが、Aは本来のAのソースコードではなくテスト用の別物と言えます。テスト用のAはAであってAでないわけです。テスト後、テスト用のAは本来のA形に編集されることになります。この時の編集でミスがあればテストの意義は著しく低下します。こうしたことを避けるためAを編集しない形でテストすることにすれば、すなわちBの完成を待つことになるのです。

上手く登録されなかったので修正

2018/05/16 19:06

投稿

Hiroshi-Aoki

スコア804

test CHANGED Viewed

@@ -1,21 +1,31 @@
-DIを使うとnewから解放されます。
+DIを使うことでソースコードの記述がクラスの依存関係から解放されます。
 **「Aクラスの中でBクラスをnewするとAはBに依存している」について**
-AクラスがBクラスを使う時、「Aクラスは、Bクラスをnewできなければならない」ですよね。Bクラスにはプロパティがあり、インスタンスが発生すると同時に初期化される必要があるとすると、初期化するのに必要な値は、コンストラクタで new B(x, y, z) なりすることになりますね。Aクラスはこの時の x, y, zの値をBに渡してあげなければならないわけです。
+AクラスがBクラスを使う時、「Aクラスは、Bクラスをnewできなければならない」ですよね。Bクラスにはプロパティがあり、インスタンスが発生すると同時に初期化される必要があるとすると、初期化するのに必要な値は、コンストラクタで new B(x, y, z) なりすることになりますね。Aクラスはこの時の x, y, zの値をBに渡してあげなければならないわけです。つまり、AはBを使うためにBを使えるようにしなければならないという依存関係があるわけです。
-つまり、AはBを使うためにBを使えるようにしなければならないという依存関係があるわけです。DIの場合、Bのプロパティはそれ自体がDIによって注入される（することができる）ようになるので、引数付きのコンストラクタは必要なくなり、引数なしのデフォルトコンストラクタのみになります。これと同時に、Aはx, y, zを知る必要がなくなり、AはBとの依存関係から解放されます。
+DIの場合、Bのプロパティはそれ自体がDIによって注入される（することができる）ようになるので、引数付きのコンストラクタは必要なくなり、引数なしのデフォルトコンストラクタのみになります。これと同時に、Aはx, y, zを知る必要がなくなり、AはBとの依存関係から解放されます。
-**「BができるまでAのテストができない」に**
+**「BができるまでAのテストができない」について**
 Aをテストするにあたり、Bをモックにするとします。
 BはモックであってBではなく、BはBで作成している最中なので同じクラス名を使うことができません。この時BのモックはBMockのような名前だったり、パッケージを変える形でテストをすることになります。結果、Aはテスト用のソースコードになります。
-一見問題なさそうに思いますが、Aは本来のAのソースコードではなくテスト用の別物と言えます。テスト用のAはAであってAでないわけです。テスト後、テスト用のAは本来のAに編集されることになります。この時の編集でミスがあればテストの意義は著しく低下します。こうしたことを避けるため十分な条件を満たそうとすれば、すなわちBの完成を待つことになるのです。
+一見問題なさそうに思いますが、Aは本来のAのソースコードではなくテスト用の別物と言えます。テスト用のAはAであってAでないわけです。テスト後、テスト用のAは本来のA形に編集されることになります。この時の編集でミスがあればテストの意義は著しく低下します。こうしたことを避けるためAを編集しない形でテストすることにすれば、すなわちBの完成を待つことになるのです。
 DIの場合、DIコンテナに本来のBを登録するか、モックのBを登録するかで、Aのソースを編集することなくAが使用するBを切り替えることが可能になります。Aは本来のAのまま、テスト後に編集されることもありません。DIを活用することで、AはBの完成を待つ必要から解放されます。
+**DIを使うことのメリットについて**
+DIは、その仕組み上、インターフェイスとデフォルトコンストラクタを求めます。これによってクラスのカプセル化はより高度化されること結果となりました。これにより、想定外のパラメータの発生リスクが最小化され、AもBもより堅牢なプログラムとなりました。アノテーションによる定義は、設定ファイルの定義からの解放を促し、人の作業によるバグの発生の可能性の低減に寄与しています。
+DIの内部構造を知ることも理解が深まると思います。[こちら](http://d.hatena.ne.jp/nowokay/20160406)でDIの仕組みについて実装体験をするのも良いかもしれません。仕組みを知ることでSpringBootの理解の援けにもなろうかと思います。