DI/DIPを体験してみよう

Transcript

1. DI-DIP勉強会 Github: @sor4chi 𝕏 Twitter: @monica18_pr
2. 今日の目標 オブジェクト指向の基本を再確認する DIとDIPの概念を理解する 保守性の高いコードを書くための考え方を学ぶ
3. おさらい
4. オブジェクト指向とは class が一般的に使われており、 データ （プロパティ）と 操作 （メソッド）をまとめて提供することができる。 オブジェクト指向とは、プログラムをオブジェクトと呼ばれ る単位で構成し、オブジェクト間の相互作用によってプログ ラムを実現する考え方である。
5. オブジェクト指向の特徴 カプセル化 継承 ポリモーフィズム
6. DIやDIPを理解するために必要な概念とは...？
7. カプセル化
8. 内部で保持しているデータに対して、外部から直接アクセスす ることを防ぐことで、データの不整合を防ぎやすい。 カプセル化とは、オブジェクトの内部にデータと操作を隠蔽 し、外部からはオブジェクトのデータに対して操作のみを行 うことができるようにすること。
9. 例えば
11. このように、外部から直接アクセスすることを防ぐことがで き、必要のない機能を露出させないことができる。
12. おさらい終わり
13. DIを体験してみる
14. ゲームのプログラムを考えましょう。 Boardがあって、その中にPlayerがいるとします。 これをオブジェクト指向で書いてみましょう。
16. 依存関係を集合として表すとこんな感じ Player Board ⊂
17. これだとBoardの中でPlayerを生成しているので、Boardと Playerは密結合(=強い依存関係)になってしまう。
18. じゃあどうすればいいの
19. DI を使えばいいじゃない
20. DIとは DI = Dependency Injection DIとは、依存性の注入と呼ばれ、クラスの外部から依存する オブジェクトを注入することで、クラスの内部で依存するオ ブジェクトを生成することを防ぐこと。
21. つまり クラス内部で他のクラスを生成しない こと
22. DIを使った改善
23. BoardのコンストラクタでPlayerを受け取るようにする
24. すると、さっきと同じBoardをこのように書いて生成すること ができる
25. よく見ると... Board内部でPlayerを生成していないことがわかる 外からPlayerを注入している
26. 結局何が嬉しいの？
27. DIをすれば、クラスを他クラスの実体がない(=依存がない)状 態でプログラムできる
28. つまり Mock ができる。
29. Mockとは テストでよく使われる用語で 環境やライブラリなどの外部要因による影響を排除して、単 体の機能をテストすること。
30. 例えばDI前のBoardクラスをテストするとき、Playerの実体が 内包されているため、Boardのテストが通る条件として Playerのテストが通る必要がある
31. 一方でDI後のBoardクラスをテストするとき、Playerの実体が 外部から注入されるため、 Playerのテストが通らなくても Boardのテストが通る
32. 他にも Date クラスをDIすることで、テスト時に固定した日 付を注入することで、テストの結果が変わらないようにするこ とができたり、 Random をDIすることで、テスト時に固定し た乱数を注入することで、テストの結果が変わらないようにす ることができたりする。
33. Web開発におけるDI
34. Web開発ではDIが必須というくらいよく使われているので、そ の例を見ていきましょう。
35. このコードはどこが問題か？
37. 予想回答1 クエリが直書きされている
38. 定数化しておくことで、クエリの変更に強くなり、再利用の ための共通化もしやすくなる。
39. 予想回答2 内部でクラスインスタンスを生成している
40. PostUsecase がDBクライアントを内包している MySQLからPostgreSQLに変更したい場合、DBクライアン トの種類を変更する必要があるかも その度に全てのDBアクセスのコードを書き直さないといけな いので大変
41. つまり DBクライアントに依存 している
42. こんなイメージ
43. DBクライアントをインターフェースを拡張することで渡すよう にしてみる
48. こうすることで、DBクライアントの種類を変更する際に、 PostUsecase のコードを変更する必要がなくなる。 -> ライブラリや環境に依存しないコードになった
49. DIを使うと クラスを抽象化して 外部から注入 することで、クラスの内部で 依存するオブジェクトを生成することを防げる。
50. DI前
51. DI後
52. レイヤーの外側に環境やライブラリが来るので、よりプログラ ムが疎になって綺麗なアーキテクチャになる。
53. この、依存関係を注入する手法のことを**DI(Dependency Injection) と呼ぶのに対して、 それをした結果依存関係が逆転することを DIP(Dependency Inversion Principle)**と呼ぶ。 直訳: 依存関係の逆転の原則
54. https://ja.wikipedia.org/wiki/依存性逆転の原則 上位モジュールはいかなるものも下位モジュールから持ち込 んではならない。双方とも抽象（例としてインターフェー ス）に依存するべきである。
55. 今回の例では、 PostUsecase が HogeDBClient に依存し ていたが、それを IDBClient という抽象化されたインター フェースに依存するようにした。
56. おまけ
57. レイヤードアーキテクチャ
58. Layered Architectureは「自分より変更されにくいものに依存 しましょう」という設計手法 より環境やライブラリなどの外的要因に依存するほど「変更さ れやすい」ので、外側に配置するようにする。 外側は変更されやすく、内側は変更されにくい という認識で十 分
59. レイヤードアーキテクチャの例
60. Clean Architecture
62. DBやDevice,Webなどのより外的環境なものほど外側に配置さ れているのがわかる。 対してEntity(=プログラム設計の最小単位)やUsecase(=サー ビスを実装するコード)などは内側に配置されている。
63. ご清聴ありがとうございました 質問などあれば気軽にどうぞ！