オブジェクト指向設計原則から学ぶアプリケーション設計(SOLID原則についてのまとめ)

Transcript

1. オブジェクト指向設計原則から 学ぶアプリケーション設計 サポーターズColab勉強会 2018/11/14 @mosmos_21
2. 目次 1. はじめに 2. ソフトウェア設計についての概要 3. オブジェクト指向設計原則の5個の原則 4. その他原則に関すること 5. まとめ 1
3. 1. はじめに 自己紹介とか 2
4. 自己紹介 【氏名】 橋本 尚儒（はしもと たかひと） 【Twitter】 もっさん @mosmos_21 【職業】 ソフトウェアエンジニア(自社製品) Java/Spring + javascript/AngularJS 【趣味】 競技プログラミング ビリヤード 3
5. 今日話すこと • SOLID原則の話 • ソフトウェア設計に役立つ原則の紹介 4
6. 今日話さないこと • オブジェクト指向とは何か • デザインパターンの詳しい話 注意 • コード例はJavaです 5
7. こんな人が対象 6 • 何となくオブジェクト指向分かった気がするけどアプリ ケーション作れない人 • デザインパターンの勉強をしたけど実際にアプリにうま く組み込めない人
8. 対象じゃない人 7 • オブジェクト指向の本質が理解できている人 • SOLID原則を完全に理解している人
9. 2. ソフトウェア設計についての概要 オブジェクト指向 + α の話 8
10. オブジェクト指向についてのおさらい • オブジェクト同士の相互作用としてシステムのふるまいをとら える考え方(Wikipediaより) • 基本的な考え方はオブジェクト同士のメッセージのやり取り • カプセル化、継承、ポリモーフィズムなどの考え方がある 9
11. オブジェクト指向についてのおさらい • カプセル化 データのアクセスを直接させない 状態の変更に制約を課すことでオブジェクトの正当性を保証する • 継承 上位オブジェクトの「ふるまい」を受け継ぐ • ポリモーフィズム オブジェクトではなく「ふるまい」そのものに注目して、処理を記 述する 10
12. デザインパターンについてのおさらい • ソフトウェア設計における設計のノウハウをまとめたもの （全部で23パターン） • 生成に関するパターン、構造に関するパターン、ふるまいに関 するパターンに分類することができる • 再利用性の高い設計がしやすかったり、技術者同士の意思疎通 が取りやすくなったりする 11
13. アプリケーションの設計方針 アプリケーションを作るときにどのように設計しますか? • オブジェクト指向? • デザインパターン? • MVC?3層アーキテクチャ? その設計、拡張性や保守性は高いですか? 12
14. 何とか設計できても… • ソフトウェア全体を見た時に変更に弱くなっている • ただ、一部分に関してみるとうまく設計できている ↓ デザインパターンはソフトウェア設計の どの部分のための設計手法でしょうか? 13
15. 3. オブジェクト指向設計原則の 5個の原則について SOLID原則の話 14
16. SOLID原則とは 1 SRP 単一責任の原則 2 OCP オープン・クローズドの原則 3 LSP リスコフの置換原則 4 ISP インターフェース分離の原則 5 DIP 依存関係逆転の原則 アプリケーションの再利用性、保守性を高くするために必要な設計 の考え方を5個の原則としてまとめた 15
17. SOLID原則に従うことのメリット 16 • 拡張性が向上する • メンテナンスがしやすくなる • テストのしやすさ • 統制された構造を持つため、読みやすく理解のしやすい
18. 3.1. 単一責任の原則 Single Responsibility Principle 17
19. 単一責任の原則 すべてのオブジェクトはたった一つの 物事に対して責任を持つ必要がある ↓ 複数の物事に対して責任を持っていると、 変更に対する柔軟性が保てなくなる 18
20. 単一責任の原則 <オブジェクトA> <オブジェクトB> 責任が複数ある状態とは? <オブジェクト> ふるまい1 ふるまい2 ふるまい2の動作が変わると二つのオブジェクトに影響が及ぶ … 19
21. 単一責任の原則 <人事部> <営業部> <社員> 労働時間の更新 業務ランクの計算 … 例）社員情報を 管理するシステム • 人事部で使う業務ランクの計算 方法が変更になる • 開発者は営業部から利用されて いることに気づかずふるまいを 変更 営業部が利用している部分の動作 がおかしくなってしまう ↓ 20
22. 単一責任の原則 責任を単一にする例(抽象クラスと実装に分ける) <人事部> <営業部> <社員:抽象クラス> 労働時間の更新 ランク計算 … <実装クラスA > <実装クラスB> ランク計算 ランク計算 21
23. 3.2. オープン・クローズドの原則 Open Closed Principle 22
24. オープン・クローズドの原則 • オープン 拡張が簡単にできる状態にしておく • クローズド 拡張を行った際に影響範囲が少なくなるようにする ロジックを追加するときは、 既存のコードをできるだけ改修せずに 新しいコードを簡単に追加できるようにする ↓ 23
25. オープン・クローズドの原則 原則が守られていない例(決済サービス) <決済管理> 支払い カード払い モジュール 電子マネー払い モジュール モジュールの修正・追加によって 支払いロジックそのものに大きな修正が入る 24
26. オープン・クローズドの原則 解決策: インターフェースに依存させる • 支払いロジックが実装に依存していない • モジュールの追加による支払ロジックの修正がない <決済管理> 支払い カード払い モジュール 電子マネー払い モジュール <インターフェース> 支払いモジュール 25
27. 3.3. リスコフの置換原則 Liskov Substitution Principle 26
28. リスコフの置換原則 27 派生した型は基本型と置換可能でなければならない ↓ 置き換えができない そもそも継承すべきではない 置き換えができる 継承関係が正しいことの指標として見れる
29. リスコフの置換原則 28 <四角形> 違反例 面積取得 Height 設定 Width 設定 <正方形> class Square extends Rectangle Rectangle r = new Square(); r.setHeight(5); r.setWidth(2); System.out.println(r.getArea()); これはどのように動作しますか?
30. リスコフの置換原則 29 置き換えができない(= ふるまいが異なる)と何が起こるか • 利用元で派生先に応じた分岐が必要になる • オープン・クローズドの原則に反する 置き換えができる状態では、 • ポリモーフィズムのメリットを最大限享受できる • オブジェクトの処理から関心を話すことができる
31. 3.4. インターフェース分離の原則 Interface Segregation Principle 30
32. インターフェース分離の原則 31 上位オブジェクトが利用しない下位オブジェクト のふるまいへの依存を強制してはならない 下位オブジェクトの無関係なふるまいが 変更されたことによる影響を受けてしまうことがある インターフェースによって依存を制限する ↓ ↓
33. インターフェース分離の原則 32 <下位オブジェクト> Method – A Method - B Method - C <インターフェース> Method – A Method – B Method – C 上位オブジェクト 上位オブジェクト 上位オブジェクト 実装を分離する (まだ不足)
34. インターフェース分離の原則 33 <下位オブジェクト> Method – A Method - B Method - C <インターフェース> Method – A <インターフェース> Method – B <インターフェース> Method – C 上位オブジェクト 上位オブジェクト 上位オブジェクト 必要なものにだけ依存させる
35. インターフェース分離の原則 34 • オブジェクト間だけでなく、モジュール間でも同じことが 言える • 依存が分離されていれば、リファクタリング、変更、障害、 再デプロイの影響が最小限になる • 結合が弱くなることにより、拡張にも強くなる
36. 3.5. 依存関係逆転の原則 Dependency Inversion Principle 35
37. 依存関係逆転の原則 36 • 上位モジュールは下位モジュールに依存してはならない • どちらのモジュールとも抽象に依存させるべき ↓ 具体的なものは変わりやすいから 詳細に依存させないため
38. 依存関係逆転の原則 37 Main Task TaskRepository 例) Todoアプリ(タスクを登録してDBに格納する) Class Task { public Task(String todo) { this.todo = todo; } public save() { TaskRepository r = new TaskRepository(); r.save(this); } }
39. 依存関係逆転の原則 38 Main Task TaskRepository 依存関係を外部から注入する Class Task { public Task(String todo, Repository repo) { this.todo = todo; this.repo = repo; } public save() { r.save(this); } } Repository
40. 依存関係逆転の原則 39 外部とは? AbstractFactory(依存の注入) 本番用メイン テスト用メイン サービス メインクラス(環境の注入) Application Service ServiceFactory
41. 4. その他原則に関すること SOLID原則だけがソフトウェア設計のすべてじゃない 40
42. コンウェイの法則 41 「システムを設計する組織は、その構造を そっくりまねた構造の設計を生み出してしまう」 • ソフトウェアを作るのは人であるからチームの構造がソフ トウェアの構造に反映される • コミュニケーションをうまくとることでソフトウェアの品 質も上がる
43. GRASPパターン 42 • オブジェクト指向設計において用いられる、クラスやオブ ジェクトに責務を割り当てる方針を導くパターンや原則であ る。(Wikipediaより) • 9個のソフトウェアに対する課題の質問と回答をまとめている 情報エキスパート 生成者 コントローラー 疎結合 高凝縮性 多態性 純粋人工物 変動からの保護 間接化
44. DRY原則 43 • Don’t Repeat Yourself. の略 • 「ソフトウェア開発においてすべての情報は単一で明確 な信頼できる表現になっていることが求められる」 • ソースコードだけでなくテストやビルドも対象 • コードであれば抽象化し、デザインパターンを活用する • テストやビルドは自動化し、人間が何度も行わない
45. 5. まとめ 全体のおさらい 44
46. まとめ 45 • オブジェクト指向での設計における原則としてSOLID原則 と呼ばれるものがある • SOLID原則を意識しながらソフトウェア設計を行うと、拡 張性、メンテナンス性が高くなりやすい • 全体の構成が洗練され、読みやすいコードを書くことが できる
47. もうちょっとだけ 46 • 今回はオブジェクト指向における設計原則 • さらに上位のコンポーネントに関する原則もいろいろあ ります • 「Clean Architecture 達人に学ぶソフトウェアの構造と 設計」という書籍に目を通してみてください
48. ご清聴ありがとうございました! ご質問がありましたらどうぞ 47