オブジェクト指向 カプセル化・ポリモーフィズム / OOP2

勉強会での登壇用資料です。
オブジェクト指向のカプセル化とポリモーフィズムについての解説です。
https://nrslib.com

Transcript

1. オブジェクト指向入門 カプセル化 ポリモーフィズム nrs @nrslib
2. カプセル化がなぜ必要か
3. カプセル化しなかったときを考えます
4. 例えばこんなクラスを使ってみます
6. このプログラム うまく動かないんですけど
7. このプログラム うまく動かないんですけど ちゃんと Strategy 設定した？
8. このプログラム うまく動かないんですけど ちゃんと Strategy 設定した？ してないじゃん
9. このプログラム うまく動かないんですけど ・・・・・・ ちゃんと Strategy 設定した？ してないじゃん
11. Strategy を設定したら Null落ちしました
12. Logger 設定してないでしょ？ Strategy を設定したら Null落ちしました
13. Logger 設定してないでしょ？ 設定しなきゃダメだよ Strategy を設定したら Null落ちしました
14. Logger 設定してないでしょ？ 設定しなきゃダメだよ ・・・・・・ Strategy を設定したら Null落ちしました
15. こんなやりとりをしたくない
16. こんなやりとりをしたくない だからカプセル化をします
17. こんなやりとりをしたくない だからカプセル化をします これならわかるよね？ ありがとうございます！
18. カプセル化
19. カプセル化 実装等を隠蔽し抽象化すること 利用法を示し実装を守る手段
20. カプセル化 難しいこと言われてもわからないよ
21. カプセル化 難しいこと言われてもわからないよ というわけで 基本的なところを ガイドラインにしてみました 法則とかは 棚上げ
22. ガイド① 初期化はコンストラクタ
23. ガイド① 初期化はコンストラクタ
24. ガイド① 初期化はコンストラクタ コンストラクタ ＝ 初期化
25. ガイド① 初期化はコンストラクタ Initialize() などのメソッドを定義しても見落とされます コンストラクタ ＝ 初期化
26. ガイド② 自由な型を便利に使わない
27. ガイド② 自由な型を便利に使わない 任意の文字列で指示する ＝ 実装を知っている
28. 任意の文字列で指示する ＝ 実装を知っている 自由度の低い型を指示子として利用します ガイド② 自由な型を便利に使わない
29. 任意の文字列で指示する ＝ 実装を知っている 自由度の低い型を指示子として利用します ガイド② 自由な型を便利に使わない
30. ガイド③ メソッドに前後関係は作らない
31. ガイド③ メソッドに前後関係は作らない 前後関係が利用者に関係ないなら内部で処理
32. ガイド④ できることを減らす
33. ガイド④ できることを減らす 一つのクラスで複数の目的を達成すると 全く関係ない処理が同じクラスに記述されます
34. ガイド④ できることを減らす 一つのクラスで複数の目的を達成すると 全く関係ない処理が同じクラスに記述されます 今後も雑多な処理がここに集まり いわゆるゴッドクラスになります
35. ガイド④ できることを減らす 目的が増えた場合は インターフェースを増やすのではなく クラスを増やします
36. ガイド④ できることを減らす 目的が増えた場合は インターフェースを増やすのではなく クラスを増やします
37. ガイド⑤ 副作用をわかりやすく
38. ガイド⑤ 副作用をわかりやすく 副作用が発生するメソッドは扱いが難しいです
39. ガイド⑤ 副作用をわかりやすく 副作用が発生するメソッドは扱いが難しいです
40. ガイド⑤ 副作用をわかりやすく 副作用が発生するメソッドは扱いが難しいです 何も起きない ……？
41. ガイド⑤ 副作用をわかりやすく 副作用が発生するメソッドは扱いが難しいです
42. ガイド⑤ 副作用をわかりやすく 副作用が発生するメソッドは扱いが難しいです
43. ガイド⑤ 副作用をわかりやすく 副作用が発生するメソッドは void 型 戻り値のあるメソッドは副作用を起こさないようにします
44. ガイド⑥ setter は使わない
45. ガイド⑥ setter は使わない 可能な限り
46. setter を用意することによって setter といずれかのメソッドが結びついていることを 意識してもらう必要ができてしまいます。 ガイド⑥ setter は使わない 可能な限り
47. setter を用意することによって setter といずれかのメソッドが結びついていることを 意識してもらう必要ができてしまいます。 ガイド⑥ setter は使わない 可能な限り
48. setter を用意することによって setter といずれかのメソッドが結びついていることを 意識してもらう必要ができてしまいます。 ガイド⑥ setter は使わない 可能な限り
49. setter を利用せず 利用するメソッドの引数や 可能ならコンストラクタで渡すようにします。 ガイド⑥ setter は使わない 可能な限り
50. ガイド⑦ getter は使わない
51. ガイド⑦ getter は使わない 可能な限り
52. setter はよく言われますが getter も不要です ガイド⑦ getter は使わない 可能な限り
53. setter はよく言われますが getter も不要です ガイド⑦ getter は使わない 可能な限り
54. setter はよく言われますが getter も不要です ← コレクションの長さをキャッシュ ガイド⑦ getter は使わない 可能な限り
55. setter はよく言われますが getter も不要です ガイド⑦ getter は使わない 可能な限り
56. クラスを getter の対象にすると 破壊ができてしまう setter はよく言われますが getter も不要です ガイド⑦ getter は使わない 可能な限り
57. getter 使わない？ じゃあどうやって結果を取得するの？
58. getter 必要
59. getter 必要 ViewModelに 変換
60. getter 必要 ↓ こういうコードに ↓ ViewModelに 変換
61. getter 必要 ↓ こういうコードに ↓ ViewModelに 変換 シンプル
62. getter を使わない場合
63. getter を使わない場合 結果を収集するクラスを作ります
64. 結果を収集 収集クラス
65. 結果を収集 収集クラス
66. 結果を収集 収集クラス ↓ 利用するとこういうコードに ↓
67. 結果を収集 収集クラス getter は消え去った ↓ 利用するとこういうコードに ↓
68. パラメータが増えたら？
69. パラメータが増えたら？
70. パラメータが増えたら？
71. getter の場合
72. getter の場合
73. 修正は簡単だけど 同じ修正を何か所でする？ getter の場合
74. 収集クラス
75. 収集クラス
76. 収集クラス
77. 収集クラス 変更箇所がここに集約
78. 収集クラス 変更箇所がここに集約
79. 収集クラス 変更箇所がここに集約 メインロジックに修正なし
80. ViewModel の種類が増えたら？
81. getter
82. getter
83. getter シンプル
84. 収集クラス
85. 収集クラス
86. 収集クラス
87. 収集クラス
88. 収集クラス メソッドが増える……。
89. 解決策
90. 解決策 ポリモーフィズム
91. 収集クラス + ポリモーフィズム
92. 収集クラス + ポリモーフィズム
93. 収集クラス + ポリモーフィズム
94. 収集クラス + ポリモーフィズム
95. 収集クラス + ポリモーフィズム クラスが増えても修正不要
96. カプセル化 まとめ ガイド① 初期化はコンストラクタ ガイド② 自由な型を便利に使わない ガイド③ メソッドに前後関係は作らない ガイド④ できることを減らす ガイド⑤ 副作用をわかりやすく ガイド⑥ setter は使わない ガイド⑦ getter は使わない
97. ポリモーフィズムの話をします
98. ポリモーフィズムの種類
99. アドホック多相 パラメータ多相 部分型付け ポリモーフィズムの種類
100. アドホック多相 パラメータ多相 部分型付け オーバーロード ジェネリクス 継承 ポリモーフィズムの種類
101. アドホック多相 パラメータ多相 部分型付け オーバーロード ジェネリクス 継承 ポリモーフィズムの種類
102. アドホック多相
103. アドホック多相
104. アドホック多相
105. アドホック多相 C# だとこの程度
106. 部分型付け
107. 部分型付け 型継承 実装継承
108. 部分型付け 型継承 実装継承 interface super class
109. 継承の話をします
110. プログラミングスタイル
111. ボトムアップ トップダウン or プログラミングスタイル
112. ボトムアップ トップダウン or プログラミングスタイル どっち？
113. ボトムアップ トップダウン or 継承を利用するとき
114. ボトムアップ トップダウン or 継承を利用するとき
115. なぜトップダウン？
116. なぜトップダウン？ カプセル化もポリモーフィズムも 抽象化のためのもの
117. なぜトップダウン？ カプセル化もポリモーフィズムも 抽象化のためのもの 抽象化はなんのため？
118. なぜトップダウン？ カプセル化もポリモーフィズムも 抽象化のためのもの 抽象化はなんのため？ 利用者のため
119. ボトムアップ
120. ボトムアップ
121. ボトムアップ 実装の共有
122. ボトムアップ 利用者からすると？
123. ボトムアップ 利用者からすると？
124. ボトムアップ 利用者からすると？ キャストが必要 Logic の処理を呼び出すには
125. ボトムアップ 利用者からすると？ キャストが必要 ＝ インスタンスの型を意識 Logic の処理を呼び出すには
126. ボトムアップ 利用者からすると？ キャストが必要 ＝ インスタンスの型を意識 Logic の処理を呼び出すには 抽象化できない
127. トップダウン
128. トップダウン
129. トップダウン ロジック二つを Roopで実行したい
130. トップダウン ロジック二つを Roopで実行したい とりあえず ILogic にして List に放り込んで
131. トップダウン ロジック二つを Roopで実行したい とりあえず ILogic にして List に放り込んで Execute()
132. トップダウン ロジック二つを Roopで実行したい あとは BusinessLogic で ILogic を実装すれば… とりあえず ILogic にして List に放り込んで Execute()
133. トップダウン できあがり
134. 実装継承は？
135. 実装継承は？ ポリモーフィズムを利用するだけなら 不要
136. 実装継承は？ ポリモーフィズムを利用するだけなら 不要 ＝ 実装継承の 目的
137. 実装継承は？ ポリモーフィズムを利用するだけなら 不要 実装者の 負担を減らす ＝ 実装継承の 目的
138. 実装継承は？ ポリモーフィズムを利用するだけなら 不要 実装者の 負担を減らす ＝ ポリモーフィズムを利用した上で 共通部分があるときに利用 実装継承の 目的
139. 継承 まとめ ポリモーフィズムの中の一つ 型継承と実装継承に分かれる トップダウンで設計をする 実装継承は実装者の負担を減らす
140. ポリモーフィズムの実践
141. 復習 ポリモーフィズムのメリットは？
142. 復習 条件分岐を減らす ポリモーフィズムのメリットは？
143. 復習 条件分岐を減らす ポリモーフィズムのメリットは？
144. 復習 条件分岐をメイン処理から移動する ポリモーフィズムのメリットは？
145. 復習 ポリモーフィズムのメリットは？ 条件分岐をメイン処理から移動する メイン処理がシンプルになる
146. メイン処理をシンプルにしてみます
148. このフィールドが 条件によって使われたり 使われなかったり
149. パターンによって 設定されたり されなかったりする値
150. お互いには全く 関係ない処理が 同じクラスの中に
151. ポリモーフィズム で 書き直そう
152. ① 処理を抽象化してクラスで実装
153. ① 処理を抽象化してクラスで実装
154. ① 処理を抽象化してクラスで実装 関係ない処理が それぞれ独立
155. ① 処理を抽象化してクラスで実装 余計な フィールドはない
156. ② 抽象化したクラスを作るメソッド or クラスを作る
157. ② 抽象化したクラスを作るメソッド or クラスを作る メソッド版
158. ② 抽象化したクラスを作るメソッド or クラスを作る メソッド版
159. ② 抽象化したクラスを作るメソッド or クラスを作る クラス版
160. ② 抽象化したクラスを作るメソッド or クラスを作る クラス版 直接利用しないフィールドが メイン処理から消えている
161. ③ 抽象化したクラスを使う
162. ③ 抽象化したクラスを使う
163. ③ 抽象化したクラスをそのまま使う ① 処理を抽象化してクラスで実装 ② 抽象化したクラスを作るメソッド or クラスを作る
164. ③ 抽象化したクラスをそのまま使う ① 処理を抽象化してクラスで実装 ② 抽象化したクラスを作るメソッド or クラスを作る ボトムアップでは？
165. ③ 抽象化したクラスをそのまま使う ① 処理を抽象化してクラスで実装 ② 抽象化したクラスを作るメソッド or クラスを作る ボトムアップでは？ →リファクタリングだったのでボトムアップになりがち
166. ① 抽象化したクラスをそのまま使うことを想定
167. ① 抽象化したクラスをそのまま使うことを想定
168. ① 抽象化したクラスをそのまま使うことを想定
169. ② 抽象化したクラスを作るメソッド or クラスを作る
170. ② 抽象化したクラスを作るメソッド or クラスを作る
171. ② 抽象化したクラスを作るメソッド or クラスを作る 具体的な処理はまだないので未実装
172. ② 抽象化したクラスを作るメソッド or クラスを作る
173. ② 抽象化したクラスを作るメソッド or クラスを作る
174. ③ 型継承して実装
175. ③ 型継承して実装
176. ③ 型継承して実装
177. ③ 型継承して実装
178. ③ 型継承して実装
179. ③ 型継承して実装
180. ③ 型継承して実装
181. ① 抽象化したクラスをそのまま使うことを想定 ② 抽象化したクラスを作るメソッド or クラスを作る ③ 型継承して実装
182. トップダウン ① 抽象化したクラスをそのまま使うことを想定 ② 抽象化したクラスを作るメソッド or クラスを作る ③ 型継承して実装
183. メリット
184. メリット 条件分岐がメイン処理から消えた
185. メリット 条件分岐がメイン処理から消えた 条件分岐が増えても = 新機能が増えても メイン処理は修正不要
186. メリット 条件分岐がメイン処理から消えた 条件分岐が増えても = 新機能が増えても メイン処理は修正不要 開放/閉鎖原則
187. いまいち使いどころが……
188. よくある MVC フレームワーク(コードはASP.net)
189. よくある MVC フレームワーク(コードはASP.net)
190. ポリモーフィズム実践 まとめ (1)抽象の生成する部分 (2)抽象を利用する部分 (3)抽象を実装する部分 この三つでワンセット
191. Auther nrs HomePage https://nrslib.com Twitter @nrslib