2025-02-27 社内勉強会 オブジェクト指向入門

Transcript

1. 第一部　クラスの使い方 2025/2/27 社内勉強会 オブジェクト指向入門 1
2. 今日のテーマ 2 simple, small
3. 3 はじめに
4. 4 • 人類は様々な考え方や方法論を生 み出し、バグと戦ってきた • すべてはバグを殲滅するため 人類の （システム開発の） 歴史はバグとの戦い
5. 5 戦いの中で人類が 手に入れた武器のひとつ • オブジェクト指向 • およびその基礎となるクラス
6. 6 オブジェクト指向 およびその基礎となるクラス 🗡🛡⚔🏹🔫
7. 7 • オブジェクト指向/クラスってなに？ • 面倒だから/難しいから使いたくない という人に • オブジェクト指向の良さを知ってもらう • クラスを使って実装したくなってもらう ことを目指す 想定読者とねらい
8. 8 • サンプルプログラムはJavaで書いています ◦ 言語によらない内容なのでJavaを知らなくても大丈夫 • 説明のために簡略化している場合があります 前置き
9. 9 オブジェクト指向とは？
10. 10 オブジェクトとは、プログラミング視点ではデータ構造とその専属手続きを一 つにまとめたものを（中略）指している。（中略）オブジェクト間の相互作用を 重視して、ソフトウェア全体を構築しようとする考え方がオブジェクト指向で ある。 Wikipediaより オブジェクト指向とは？
11. 11 • オブジェクトとは、数値などのデータと、それらを扱うロジックをひとまとめ にしたもの • オブジェクト同士を連携させてシステム全体を構築する考え方を オブジェクト指向という ※オブジェクト≒クラス オブジェクト指向とは？（意訳）
12. 例えばこんなかんじ： Moneyクラス 12
13. 例えばこんなかんじ： Moneyクラス 13 金額を表すデータ 金額データを扱う ロジック
14. 14 データとロジックを ひとまとめにして、 それを組み合わせる オブジェクト指向とは
15. 15 戦いの中で人類が 手に入れた武器のひとつ • オブジェクト指向 • およびその基礎となるクラス
16. 16 オブジェクト指向が なぜバグに有効なのか？ データとロジックをひとまとめにする
17. 17 そもそも、バグはなぜ発生する？
18. 18 人間の 1. 勘違い 2. 考慮もれ これらはプログラムの「複雑さ」「大きさ」 に起因する そもそも、バグはなぜ発生する？
19. 19 • if文の範囲を把握しづらい ◦ 勘違いしやすい • 処理のパターンが多い ◦ 考慮もれに繋がる 例えば： 何重にもネストした if文
20. 20 • if文の範囲を把握しづらい ◦ 勘違いしやすい • 処理のパターンが多い ◦ 考慮もれに繋がる 例えば： 何重にもネストした if文 金額が1000円以上なら割引する、 という処理を追加したい場合 どこに書く？
21. 21 • どこで何が行われているか 把握できない ◦ 勘違い ◦ 修正もれ（考慮もれ） 例えば：長〜い関数
22. 22 • どこで何が行われているか 把握できない ◦ 勘違い ◦ 修正もれ（考慮もれ） 例えば：長〜い関数 ここで定義された変数が ここで使われていたら？
23. 23 • そこでオブジェクト指向 • 例えば「金額」クラス プログラムの 「複雑さ」「大きさ」 を抑制したい
24. プログラムの 「複雑さ」「大きさ」 を抑制したい 24 金額に関するデータと 金額に関する処理を 切り出してまとめる
25. 25 複雑で大きい プログラムを 意味的にまとまった 小さいクラスに分割し、 クラスの中に 複雑さを閉じ込める オブジェクト指向が示した解決策
26. 26 複雑で大きいプログラムを 意味的にまとまった 小さいクラスに分割し、 クラスの中に複雑さを閉じ込める おや？
27. 27 • 無秩序な複雑さから 複雑さは変わらない？ 複雑で大きい プログラム
28. 28 • 無秩序な複雑さからコントロールされた複雑さへ 複雑さは変わらない？ 抽出 複雑な 金額クラス 複雑で大きい （金額以外の） プログラム
29. 29 同じ100行の処理でも、、、 金額の計算をしてたり 在庫数を調整してたり よくわかんない よくわかんないけど、 とにかく金額の計算をしている A B
30. 30 同じ100行の処理でも、、、 金額の計算をしてたり 在庫数を調整してたり よくわかんない よくわかんないけど、 とにかく金額の計算をしている A B こっちの方が 安心じゃないですか？
31. 31 同じ100行の処理でも、、、 金額の計算をしてたり 在庫数を調整してたり よくわかんない よくわかんないけど、 とにかく金額の計算をしている A B こっちの方が 安心じゃないですか？ ＝同時に気にするべき 　ことが少ない
32. 32 同じ100行の処理でも、、、 金額の計算をしてたり 在庫数を調整してたり よくわかんない よくわかんないけど、 とにかく金額の計算をしている A B こっちの方が 安心じゃないですか？ ＝同時に気にするべき 　ことが少ない ＝コントロールされた　 複雑さ
33. 抽出 複雑な 金額クラス 複雑で大きい （金額以外の） プログラム 33 オブジェクト指向が提供する単純さ ここに現れる金額の処理は 単純になる この金額の処理は複雑だが コントロールされている
34. 34 • 使う側の単純さ オブジェクト指向が提供する単純さ
35. 35 • 使う側の単純さ オブジェクト指向が提供する単純さ 税率が何％とか、税額の計算方法を 考えなくてよい 税率を変更しても、計算方法を変えても、 使う側に全く影響がない
36. 36 複雑で大きい プログラムを 意味的にまとまった 小さいクラスに分割し、 クラスの中に 複雑さを閉じ込めて 使う側を単純にする オブジェクト指向がバグに有効な理由
37. 37 simple, small 出ました✌
38. 38 • バグは「複雑さ」と「大きさ」から生まれる • オブジェクト指向はプログラムの複雑さを 小さいクラスの中に閉じ込めて、使う側の単純さを担保する考え方 ここまでのまとめ
39. 39 どうやって simple, small を 実現するの？
40. 40 1. 値オブジェクト ◦ 値を扱うための専用クラス 2. コレクションオブジェクト（ファーストクラスコレクション） ◦ コレクションを扱うための専用クラス ２つのテクニック
41. 41 1. 値オブジェクト ◦ 値を扱うための専用クラス 2. コレクションオブジェクト（ファーストクラスコレクション） ◦ コレクションを扱うための専用クラス ２つのテクニック
42. 42 • 数量や金額などを表現したいとき、どうしますか？ • int や BigDecimal などの基本データ型を使うことが多い 1. 値オブジェクト - 基本データ型 の落とし穴 int, BigDecimal, String, LocalDate など はじめから用意されている型
43. 43 • int はマイナス21億からプラス21億までの整数、 BigDecimal は実質無限の範囲の数値を表現できる 1. 値オブジェクト - 基本データ型 の落とし穴 int, BigDecimal, String, LocalDate など はじめから用意されている型
44. 44 • int はマイナス21億からプラス21億までの整数、 BigDecimal は実質無限の範囲の数値を表現できる 1. 値オブジェクト - 基本データ型 の落とし穴 int, BigDecimal, String, LocalDate など はじめから用意されている型 業務上の異常値を表現できてしまうと、 システムが複雑化し、バグが混入する原因になる その範囲、 本当に必要？
45. 45 Quantityクラスを使う限り 数値が1〜100であると 保証される 値の範囲を 制限した例
46. 46 • 値を上書きする（できる）＝複雑 • その瞬間にどんな値になっているか、処理を追わないとわからない 1. 値オブジェクト - 不変にする 悪い例
47. 47 • 値を上書きする（できる）＝複雑 • その瞬間にどんな値になっているか、処理を追わないとわからない 1. 値オブジェクト - 不変にする 悪い例 3,000円 1,000円
48. 48 • 値を上書きさせず、変数を分ける＝単純 • 一つひとつのオブジェクトの用途を限定する 1. 値オブジェクト - 不変にする 良い例
49. 49 不変にするやり方： 1. コンストラクタで値をすべて設定する 2. 値を変更するメソッド（setterメソッド）を作らない 3. 別の値が必要であれば、別のオブジェクトをつくる 1. 値オブジェクト - 不変にする
50. 50 不変な 値オブジェクトの例 1. コンストラクタで 値を全て設定する 2. 値を変更するメソッド （setterメソッド）を作らない 3. 別の値が必要であれば、 別のオブジェクトを作る
51. 51 • 基本データ型だけで書いたプログラムは、思わぬバグをうむ • 例えば、単価と数量をかけて金額を求める処理 1. 値オブジェクト - 型を使って意図を明確にする
52. 52 • 基本データ型だけで書いたプログラムは、思わぬバグをうむ • 例えば、単価と数量をかけて金額を求める処理 1. 値オブジェクト - 型を使って意図を明確にする エラーにならず実行できてバグ発生
53. 53 • 基本データ型だけで書いたプログラムは、思わぬバグをうむ • 例えば、単価と数量をかけて金額を求める処理 1. 値オブジェクト - 型を使って意図を明確にする
54. 54 • 基本データ型だけで書いたプログラムは、思わぬバグをうむ • 例えば、単価と数量をかけて金額を求める処理 1. 値オブジェクト - 型を使って意図を明確にする 実行前にエラーに気づく
55. 55 1. 値オブジェクト ◦ 値を扱うための専用クラス 2. コレクションオブジェクト（ファーストクラスコレクション） ◦ コレクションを扱うための専用クラス ２つのテクニック
56. 56 配列やコレクションを使おうとすると、以下のような処理が頻出する 1. for 文などループ処理のロジック 2. 配列やコレクションの要素の数が変化する（可能性がある） 3. 個々の要素の内容が変化する（可能性がある） 4. ゼロ件の場合の処理 5. 要素の最大件数の制限 2. コレクションオブジェクト - 　配列やコレクションはコードを複雑にする このようなコードがあちこちに散らばると、 プログラムが複雑になりがち
57. 57 • 考え方は値オブジェクトと同じ • コレクション型の変数を 1つだけ持った専用クラス • コレクションを操作する ロジックをすべて集める ◦ 追加、削除、カウント、 特定条件の絞り込み、etc. 2. コレクションオブジェクト - 　コレクションを扱うための専用クラス
58. 58 • 値オブジェクトと同様、できるだけ不変にする 不変にするやり方： 1. コレクション操作のロジックをコレクションオブジェクトに移動する 2. コレクション操作の結果も同じ型のコレクションオブジェクトとして返す 3. コレクションを不変にして外部に渡す 2. コレクションオブジェクト - 不変にする
59. 59 • コレクション変数をそのまま返すメソッドを用意しない ◦ クラスの外部でコレクションを操作できてしまう 2. コレクションオブジェクト - 不変にする 悪い例 1. コレクション操作のロジックをコレクションオブジェクトに移動する 2. コレクション操作の結果も同じ型のコレクションオブジェクトとして返す 3. コレクションを不変にして外部に渡す
60. 60 • 外部でやりたい操作を、クラスに集められないか検討する • 操作の結果を同じ型のコレクションオブジェクトとして返す 2. コレクションオブジェクト - 不変にする 良い例 1. コレクション操作のロジックをコレクションオブジェクトに移動する 2. コレクション操作の結果も同じ型のコレクションオブジェクトとして返す 3. コレクションを不変にして外部に渡す
61. 61 • どうしてもコレクションを渡す必要がある場合、 変更できないコレクションを返す 2. コレクションオブジェクト - 不変にする 良い例 1. コレクション操作のロジックをコレクションオブジェクトに移動する 2. コレクション操作の結果も同じ型のコレクションオブジェクトとして返す 3. コレクションを不変にして外部に渡す
62. 62 1. 値オブジェクト 2. コレクションオブジェクト（ファーストクラスコレクション） ２つのテクニック
63. 63 1. 値オブジェクト 2. コレクションオブジェクト（ファーストクラスコレクション） →　カプセル化 • データとロジックをひとまとめのクラスにする • データの操作は、クラス内部のロジックで行う • クラスの外部からデータを操作させない • 内部に複雑さを閉じ込めて、外部からの利用を単純にする ２つのテクニック
64. 64 • オブジェクト指向プログラミングの３大要素 a. カプセル化 b. ポリモーフィズム c. 継承 • SOLID原則 • デザインパターン • ドメイン駆動設計 オブジェクト指向を使いこなす次のステップ
65. 65 参考文献
66. これだけ覚えて帰ってください 66 simple, small
67. 67 Appendix
68. 68 • カプセル化 • ポリモーフィズム ◦ 別々のクラスを同じように扱う • 継承 ◦ 同系統のクラスを分類する オブジェクト指向プログラミングの３大要素
69. 69 保守性の高い設計の指針 1. 単一責任の原則 Single-responsibility principle 2. 開放閉鎖の原則 Open/closed principle 3. リスコフの置換原則 Liskov substitution principle 4. インターフェース分離の原則 Interface segregation principle 5. 依存性逆転の原則 Dependency inversion principle SOLID原則
70. 70 • ソフトウェア開発で頻出する設計のパターン集 ◦ Strategy パターン ◦ Builder パターン　etc. • Iterator パターンが最も身近だと思う ◦ Javaの拡張 for 文（for (Foo foo : barList)）は これで実装されている • Composite パターンもイメージしやすいかも ◦ ファイルシステムのフォルダとファイルの関係はこれ デザインパターン