Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
オブジェクト指向 カプセル化・ポリモーフィズム / OOP2
Search
nrs
June 20, 2018
Programming
5
5k
オブジェクト指向 カプセル化・ポリモーフィズム / OOP2
勉強会での登壇用資料です。
オブジェクト指向のカプセル化とポリモーフィズムについての解説です。
https://nrslib.com
nrs
June 20, 2018
Tweet
Share
More Decks by nrs
See All by nrs
/←このスケジュール表に立ち向かう フロントエンド開発戦略 / A front-end development strategy to tackle a single-slash schedule.
nrslib
1
680
Pythonによるイベントソーシングへの挑戦と現状に対する考察 / Challenging Event Sourcing with Python and Reflections on the Current State
nrslib
3
1.5k
デザインシステムとコンポーネント指向によるフロントエンド開発プロセスの革新 / Innovation in Frontend Development Processes through Design Systems and Component-Oriented Architecture
nrslib
9
5.9k
さきがけから振り返るアーキテクチャ刷新 / Reflecting on the Architectural Renewal from the Vanguard
nrslib
7
2.1k
ぼっちを避けて楽しむためのアノテコノテ / Various Tips and Tricks to Avoid Loneliness and Have Fun
nrslib
3
2.4k
イベント駆動アーキテクチャ導入の手引きと共通の落とし穴 / Guide to Implementing Event-Driven Architecture and Common Pitfalls
nrslib
12
4.9k
CQRS+ES解体新書 / CQRS ES Disassembly Book
nrslib
7
2.9k
イベントストーミングによるオブジェクトモデリング・オブジェクト指向プログラミングの適用・開発プロセスの変遷・アーキテクチャの変革 / Object modeling with Event Storming.
nrslib
13
7.1k
Deep Dive 大規模システムアーキテクチャ/開発組織エンジニアリング / Deep Dive Large-Scale System Architecture, Development Organization Engineering
nrslib
16
3.6k
Other Decks in Programming
See All in Programming
カンファレンスの「アレ」Webでなんとかしませんか? / Conference “thing” Why don't you do something about it on the Web?
dero1to
1
110
Pinia Colada が実現するスマートな非同期処理
naokihaba
4
230
as(型アサーション)を書く前にできること
marokanatani
10
2.7k
3rd party scriptでもReactを使いたい! Preact + Reactのハイブリッド開発
righttouch
PRO
1
610
Snowflake x dbtで作るセキュアでアジャイルなデータ基盤
tsoshiro
2
520
ECS Service Connectのこれまでのアップデートと今後のRoadmapを見てみる
tkikuc
2
250
macOS でできる リアルタイム動画像処理
biacco42
9
2.4k
型付き API リクエストを実現するいくつかの手法とその選択 / Typed API Request
euxn23
8
2.3k
C++でシェーダを書く
fadis
6
4.1k
イベント駆動で成長して委員会
happymana
1
340
Compose 1.7のTextFieldはPOBox Plusで日本語変換できない
tomoya0x00
0
200
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
100
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Speed Design
sergeychernyshev
25
620
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
430
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Typedesign – Prime Four
hannesfritz
40
2.4k
GraphQLとの向き合い方2022年版
quramy
43
13k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
5.3k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.2k
Keith and Marios Guide to Fast Websites
keithpitt
409
22k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.3k
Gamification - CAS2011
davidbonilla
80
5k
Transcript
オブジェクト指向入門 カプセル化 ポリモーフィズム nrs @nrslib
カプセル化がなぜ必要か
カプセル化しなかったときを考えます
例えばこんなクラスを使ってみます
None
このプログラム うまく動かないんですけど
このプログラム うまく動かないんですけど ちゃんと Strategy 設定した?
このプログラム うまく動かないんですけど ちゃんと Strategy 設定した? してないじゃん
このプログラム うまく動かないんですけど ・・・・・・ ちゃんと Strategy 設定した? してないじゃん
None
Strategy を設定したら Null落ちしました
Logger 設定してないでしょ? Strategy を設定したら Null落ちしました
Logger 設定してないでしょ? 設定しなきゃダメだよ Strategy を設定したら Null落ちしました
Logger 設定してないでしょ? 設定しなきゃダメだよ ・・・・・・ Strategy を設定したら Null落ちしました
こんなやりとりをしたくない
こんなやりとりをしたくない だからカプセル化をします
こんなやりとりをしたくない だからカプセル化をします これならわかるよね? ありがとうございます!
カプセル化
カプセル化 実装等を隠蔽し抽象化すること 利用法を示し実装を守る手段
カプセル化 難しいこと言われてもわからないよ
カプセル化 難しいこと言われてもわからないよ というわけで 基本的なところを ガイドラインにしてみました 法則とかは 棚上げ
ガイド① 初期化はコンストラクタ
ガイド① 初期化はコンストラクタ
ガイド① 初期化はコンストラクタ コンストラクタ = 初期化
ガイド① 初期化はコンストラクタ Initialize() などのメソッドを定義しても見落とされます コンストラクタ = 初期化
ガイド② 自由な型を便利に使わない
ガイド② 自由な型を便利に使わない 任意の文字列で指示する = 実装を知っている
任意の文字列で指示する = 実装を知っている 自由度の低い型を指示子として利用します ガイド② 自由な型を便利に使わない
任意の文字列で指示する = 実装を知っている 自由度の低い型を指示子として利用します ガイド② 自由な型を便利に使わない
ガイド③ メソッドに前後関係は作らない
ガイド③ メソッドに前後関係は作らない 前後関係が利用者に関係ないなら内部で処理
ガイド④ できることを減らす
ガイド④ できることを減らす 一つのクラスで複数の目的を達成すると 全く関係ない処理が同じクラスに記述されます
ガイド④ できることを減らす 一つのクラスで複数の目的を達成すると 全く関係ない処理が同じクラスに記述されます 今後も雑多な処理がここに集まり いわゆるゴッドクラスになります
ガイド④ できることを減らす 目的が増えた場合は インターフェースを増やすのではなく クラスを増やします
ガイド④ できることを減らす 目的が増えた場合は インターフェースを増やすのではなく クラスを増やします
ガイド⑤ 副作用をわかりやすく
ガイド⑤ 副作用をわかりやすく 副作用が発生するメソッドは扱いが難しいです
ガイド⑤ 副作用をわかりやすく 副作用が発生するメソッドは扱いが難しいです
ガイド⑤ 副作用をわかりやすく 副作用が発生するメソッドは扱いが難しいです 何も起きない ……?
ガイド⑤ 副作用をわかりやすく 副作用が発生するメソッドは扱いが難しいです
ガイド⑤ 副作用をわかりやすく 副作用が発生するメソッドは扱いが難しいです
ガイド⑤ 副作用をわかりやすく 副作用が発生するメソッドは void 型 戻り値のあるメソッドは副作用を起こさないようにします
ガイド⑥ setter は使わない
ガイド⑥ setter は使わない 可能な限り
setter を用意することによって setter といずれかのメソッドが結びついていることを 意識してもらう必要ができてしまいます。 ガイド⑥ setter は使わない 可能な限り
setter を用意することによって setter といずれかのメソッドが結びついていることを 意識してもらう必要ができてしまいます。 ガイド⑥ setter は使わない 可能な限り
setter を用意することによって setter といずれかのメソッドが結びついていることを 意識してもらう必要ができてしまいます。 ガイド⑥ setter は使わない 可能な限り
setter を利用せず 利用するメソッドの引数や 可能ならコンストラクタで渡すようにします。 ガイド⑥ setter は使わない 可能な限り
ガイド⑦ getter は使わない
ガイド⑦ getter は使わない 可能な限り
setter はよく言われますが getter も不要です ガイド⑦ getter は使わない 可能な限り
setter はよく言われますが getter も不要です ガイド⑦ getter は使わない 可能な限り
setter はよく言われますが getter も不要です ← コレクションの長さをキャッシュ ガイド⑦ getter は使わない 可能な限り
setter はよく言われますが getter も不要です ガイド⑦ getter は使わない 可能な限り
クラスを getter の対象にすると 破壊ができてしまう setter はよく言われますが getter も不要です ガイド⑦ getter
は使わない 可能な限り
getter 使わない? じゃあどうやって結果を取得するの?
getter 必要
getter 必要 ViewModelに 変換
getter 必要 ↓ こういうコードに ↓ ViewModelに 変換
getter 必要 ↓ こういうコードに ↓ ViewModelに 変換 シンプル
getter を使わない場合
getter を使わない場合 結果を収集するクラスを作ります
結果を収集 収集クラス
結果を収集 収集クラス
結果を収集 収集クラス ↓ 利用するとこういうコードに ↓
結果を収集 収集クラス getter は消え去った ↓ 利用するとこういうコードに ↓
パラメータが増えたら?
パラメータが増えたら?
パラメータが増えたら?
getter の場合
getter の場合
修正は簡単だけど 同じ修正を何か所でする? getter の場合
収集クラス
収集クラス
収集クラス
収集クラス 変更箇所がここに集約
収集クラス 変更箇所がここに集約
収集クラス 変更箇所がここに集約 メインロジックに修正なし
ViewModel の種類が増えたら?
getter
getter
getter シンプル
収集クラス
収集クラス
収集クラス
収集クラス
収集クラス メソッドが増える……。
解決策
解決策 ポリモーフィズム
収集クラス + ポリモーフィズム
収集クラス + ポリモーフィズム
収集クラス + ポリモーフィズム
収集クラス + ポリモーフィズム
収集クラス + ポリモーフィズム クラスが増えても修正不要
カプセル化 まとめ ガイド① 初期化はコンストラクタ ガイド② 自由な型を便利に使わない ガイド③ メソッドに前後関係は作らない ガイド④ できることを減らす
ガイド⑤ 副作用をわかりやすく ガイド⑥ setter は使わない ガイド⑦ getter は使わない
ポリモーフィズムの話をします
ポリモーフィズムの種類
アドホック多相 パラメータ多相 部分型付け ポリモーフィズムの種類
アドホック多相 パラメータ多相 部分型付け オーバーロード ジェネリクス 継承 ポリモーフィズムの種類
アドホック多相 パラメータ多相 部分型付け オーバーロード ジェネリクス 継承 ポリモーフィズムの種類
アドホック多相
アドホック多相
アドホック多相
アドホック多相 C# だとこの程度
部分型付け
部分型付け 型継承 実装継承
部分型付け 型継承 実装継承 interface super class
継承の話をします
プログラミングスタイル
ボトムアップ トップダウン or プログラミングスタイル
ボトムアップ トップダウン or プログラミングスタイル どっち?
ボトムアップ トップダウン or 継承を利用するとき
ボトムアップ トップダウン or 継承を利用するとき
なぜトップダウン?
なぜトップダウン? カプセル化もポリモーフィズムも 抽象化のためのもの
なぜトップダウン? カプセル化もポリモーフィズムも 抽象化のためのもの 抽象化はなんのため?
なぜトップダウン? カプセル化もポリモーフィズムも 抽象化のためのもの 抽象化はなんのため? 利用者のため
ボトムアップ
ボトムアップ
ボトムアップ 実装の共有
ボトムアップ 利用者からすると?
ボトムアップ 利用者からすると?
ボトムアップ 利用者からすると? キャストが必要 Logic の処理を呼び出すには
ボトムアップ 利用者からすると? キャストが必要 = インスタンスの型を意識 Logic の処理を呼び出すには
ボトムアップ 利用者からすると? キャストが必要 = インスタンスの型を意識 Logic の処理を呼び出すには 抽象化できない
トップダウン
トップダウン
トップダウン ロジック二つを Roopで実行したい
トップダウン ロジック二つを Roopで実行したい とりあえず ILogic にして List に放り込んで
トップダウン ロジック二つを Roopで実行したい とりあえず ILogic にして List に放り込んで Execute()
トップダウン ロジック二つを Roopで実行したい あとは BusinessLogic で ILogic を実装すれば… とりあえず ILogic
にして List に放り込んで Execute()
トップダウン できあがり
実装継承は?
実装継承は? ポリモーフィズムを利用するだけなら 不要
実装継承は? ポリモーフィズムを利用するだけなら 不要 = 実装継承の 目的
実装継承は? ポリモーフィズムを利用するだけなら 不要 実装者の 負担を減らす = 実装継承の 目的
実装継承は? ポリモーフィズムを利用するだけなら 不要 実装者の 負担を減らす = ポリモーフィズムを利用した上で 共通部分があるときに利用 実装継承の 目的
継承 まとめ ポリモーフィズムの中の一つ 型継承と実装継承に分かれる トップダウンで設計をする 実装継承は実装者の負担を減らす
ポリモーフィズムの実践
復習 ポリモーフィズムのメリットは?
復習 条件分岐を減らす ポリモーフィズムのメリットは?
復習 条件分岐を減らす ポリモーフィズムのメリットは?
復習 条件分岐をメイン処理から移動する ポリモーフィズムのメリットは?
復習 ポリモーフィズムのメリットは? 条件分岐をメイン処理から移動する メイン処理がシンプルになる
メイン処理をシンプルにしてみます
None
このフィールドが 条件によって使われたり 使われなかったり
パターンによって 設定されたり されなかったりする値
お互いには全く 関係ない処理が 同じクラスの中に
ポリモーフィズム で 書き直そう
① 処理を抽象化してクラスで実装
① 処理を抽象化してクラスで実装
① 処理を抽象化してクラスで実装 関係ない処理が それぞれ独立
① 処理を抽象化してクラスで実装 余計な フィールドはない
② 抽象化したクラスを作るメソッド or クラスを作る
② 抽象化したクラスを作るメソッド or クラスを作る メソッド版
② 抽象化したクラスを作るメソッド or クラスを作る メソッド版
② 抽象化したクラスを作るメソッド or クラスを作る クラス版
② 抽象化したクラスを作るメソッド or クラスを作る クラス版 直接利用しないフィールドが メイン処理から消えている
③ 抽象化したクラスを使う
③ 抽象化したクラスを使う
③ 抽象化したクラスをそのまま使う ① 処理を抽象化してクラスで実装 ② 抽象化したクラスを作るメソッド or クラスを作る
③ 抽象化したクラスをそのまま使う ① 処理を抽象化してクラスで実装 ② 抽象化したクラスを作るメソッド or クラスを作る ボトムアップでは?
③ 抽象化したクラスをそのまま使う ① 処理を抽象化してクラスで実装 ② 抽象化したクラスを作るメソッド or クラスを作る ボトムアップでは? →リファクタリングだったのでボトムアップになりがち
① 抽象化したクラスをそのまま使うことを想定
① 抽象化したクラスをそのまま使うことを想定
① 抽象化したクラスをそのまま使うことを想定
② 抽象化したクラスを作るメソッド or クラスを作る
② 抽象化したクラスを作るメソッド or クラスを作る
② 抽象化したクラスを作るメソッド or クラスを作る 具体的な処理はまだないので未実装
② 抽象化したクラスを作るメソッド or クラスを作る
② 抽象化したクラスを作るメソッド or クラスを作る
③ 型継承して実装
③ 型継承して実装
③ 型継承して実装
③ 型継承して実装
③ 型継承して実装
③ 型継承して実装
③ 型継承して実装
① 抽象化したクラスをそのまま使うことを想定 ② 抽象化したクラスを作るメソッド or クラスを作る ③ 型継承して実装
トップダウン ① 抽象化したクラスをそのまま使うことを想定 ② 抽象化したクラスを作るメソッド or クラスを作る ③ 型継承して実装
メリット
メリット 条件分岐がメイン処理から消えた
メリット 条件分岐がメイン処理から消えた 条件分岐が増えても = 新機能が増えても メイン処理は修正不要
メリット 条件分岐がメイン処理から消えた 条件分岐が増えても = 新機能が増えても メイン処理は修正不要 開放/閉鎖原則
いまいち使いどころが……
よくある MVC フレームワーク(コードはASP.net)
よくある MVC フレームワーク(コードはASP.net)
ポリモーフィズム実践 まとめ (1)抽象の生成する部分 (2)抽象を利用する部分 (3)抽象を実装する部分 この三つでワンセット
Auther nrs HomePage https://nrslib.com Twitter @nrslib