✨ budougumi0617: add warning to DI

Author: budougumi0617

articles/budougumi0617.re

@@ -685,20 +685,23 @@ func main() {
 //footnote[wire][@<href>{https://github.com/google/wire}]
 //footnote[simplicity][@<href>{https://employment.en-japan.com/engineerhub/entry/2018/06/19/110000}]
 
-== 終わりに
-　本章では、SOLIDの原則のおさらいをしました。
-そして、SOLIDの原則の各原則が@<tt>{Go}のプログラミングの中でどう表出されるのか確かめました。
-@<tt>{Go}は一般にオブジェクト指向言語と呼ばれるプログラミング言語がもつ特徴を十分に備えていません。
-そのような@<tt>{Go}でもオブジェクト指向設計のプラクティスや原則を守ることで、よりよいいコードを書くことができます。
+=== @<tt>{依存関係逆転の原則}と@<tt>{Go}
+　@<tt>{DIP}を使うことでパッケージ間、構造体間の結合度を下げることができます。
+ただし、早すぎたり過剰な抽象化はソースコードの可読性を下げたり、手戻りが発生しやすくなります。
+他言語で@<tt>{DI}ツールが重宝されるのは以下の理由もあります。
+
+ * @<tt>{DLL}ファイルや@<tt>{Jar}ファイルから実行時に動的にクラスをロードできる
+ * フレームワークや@<tt>{UI}に依存した実装を避けたい
 
-　ただし、早すぎたり過剰な抽象化はソースコードの可読性を下げたり、手戻りが発生しやすくなります。
-特に、@<code>{interface}を使った過剰な抽象化には注意が必要です。
+データベースに依存させたくないなどの理由がある場合など、@<tt>{DI}の利用は適切に用法用量を守って使いましょう。
+　特に、@<code>{interface}を使った過剰な抽象化には注意が必要です。
 @<tt>{Go}はインターフェースを使ったダックタイピングを採用しているため、次の箇条書きの情報を得るにはIDEなどの助けが必要になります。
 
  * ある@<tt>{struct}がどの@<code>{interface}を継承しているのか
  * ある@<code>{interface}を継承している@<tt>{struct}はどれだけ存在しているのか
 
-@<list>{ensure_interface}は@<code>{Knight}型が@<code>{Jedi}インターフェースを満たしているか、コンパイル時に検証させる方法です@<fn>{ensure}。
+現実的な解法の1つとして、ある構造体（実装の詳細）が特定のインターフェースを実装しているかコンパイラにチェックさせる方法があります@<fn>{ensure}。
+@<list>{ensure_interface}は@<code>{Knight}型が@<code>{Jedi}インターフェースを満たしているか、コンパイル時に検証させる方法です。
 このようなプラクティスはあるものの、過剰な抽象化をしないように気を付けましょう。
 
 //list[ensure_interface][コンパイラを使った実装チェック]{
@@ -714,7 +717,11 @@ var _ Jedi = (*Knight)(nil)
 
 //footnote[ensure][@<href>{https://splice.com/blog/golang-verify-type-implements-interface-compile-time/}]
 
-
+== 終わりに
+　本章では、SOLIDの原則のおさらいをしました。
+そして、SOLIDの原則の各原則が@<tt>{Go}のプログラミングの中でどう表出されるのか確かめました。
+@<tt>{Go}は一般にオブジェクト指向言語と呼ばれるプログラミング言語がもつ特徴を十分に備えていません。
+そのような@<tt>{Go}でもオブジェクト指向設計のプラクティスや原則を守ることで、よりよいいコードを書くことができます。
 
 == 参考文献
 最後に、本章を執筆するにあたって参考にした書籍を挙げておきます。