SlideShare une entreprise Scribd logo
1  sur  45
Télécharger pour lire hors ligne
SOLID原則
佐久間 尚輝
自己紹介
では、本題へ
アジェンダ
SOLID原則とは?
SOLID原則の中身
- 単一責任の原則
- オープン・クローズドの原則
- リスコフの置換原則
- 依存関係逆転の原則
- インターフェース分離の原則
まとめ
アジェンダ
SOLID原則とは?
SOLID原則の中身
- 単一責任の原則
- オープン・クローズドの原則
- リスコフの置換原則
- 依存関係逆転の原則
- インターフェース分離の原則
まとめ
SOLID原則とは?
In object-oriented computer programming, the
term SOLID is a mnemonic acronym for five
design principles intended to make software
designs more understandable, flexible
and maintainable. The principles are a subset of
many principles promoted by Robert C.
Martin. Though they apply to any object-
oriented design, the SOLID principles can also
form a core philosophy for methodologies such
as agile development or adaptive software
development.(wikipediaより抜粋)
完
ちゃんと説明させて
いただきます
SOLID原則とは?
ソフトウェアの設計を
理解しやすく柔軟にすることを
目的とした5つの設計原則のこと
(オブジェクト指向のようなもの)
アジェンダ
SOLID原則とは?
SOLID原則の中身
- 単一責任の原則
- オープン・クローズドの原則
- リスコフの置換原則
- 依存関係逆転の原則
- インターフェース分離の原則
まとめ
SOLID原則の中身
単一責任の原則
- Single responsibility principle
オープン・クローズドの原則
- Open/closed principle
リスコフの置換原則
- Liskov substitution principle
依存関係逆転の原則
- Interface segregation principle
インターフェース分離の原則
- Dependency inversion principle
アジェンダ
SOLID原則とは?
SOLID原則の中身
- 単一責任の原則
- オープン・クローズドの原則
- リスコフの置換原則
- 依存関係逆転の原則
- インターフェース分離の原則
まとめ
単一責任の原則
クラスを変更する理由は
2つ以上存在してはならない
どういうこと?
1つのクラスには1つの役割
悪い例
PlayerManagerクラス
何が悪いの?
・1つのクラスの役割が多すぎる
・機能の修正、追加をする際
思わぬところで不具合が
発生する可能性がある
改善
PlayerMoveクラス
PlayerAttackクラス
PlayerEffectクラス
処理ごとにクラスを分ける
アジェンダ
SOLID原則とは?
SOLID原則の中身
- 単一責任の原則
- オープン・クローズドの原則
- リスコフの置換原則
- 依存関係逆転の原則
- インターフェース分離の原則
まとめ
オープン・クローズドの原則
クラスは
拡張に対して開いていて、
修正に対して閉じて
いなければならない
どういうこと?
仕様変更があった場合は
機能の追加を容易に出来る
その際に既存のコードは
影響をうけない
悪い例
プレイヤーの当たり判定
何が悪いの?
・処理を記述し忘れても気付けない
・当たり判定が増えるたびに
このif文が増える
改善
if文の羅列もなくなり
変更に強いコードに
Playerクラス
改善
基底クラスやインターフェースを使って
抽象化する
当たったときの
インターフェース Enemyクラス
アジェンダ
SOLID原則とは?
SOLID原則の中身
- 単一責任の原則
- オープン・クローズドの原則
- リスコフの置換原則
- 依存関係逆転の原則
- インターフェース分離の原則
まとめ
リスコフの置換原則
派生クラスはその基底クラスと
置換可能でなければならない
どういうこと?
基底クラスで決められた約束を
派生クラスで破ってはいけない
悪い例
値段クラス
税込み価格クラス
悪い例クラス
何が悪いの?
計算機クラス
・結果が違っているのに動いてしまう
・親クラスが望んでいる結果と違う
・チーム制作で起こりやすい
税込み価格クラスの
処理を知らない人が
作ったクラス
改善
税込み価格クラス
専用の属性を用意してあげると
親の挙動を変更せずに
処理がおこなえる
アジェンダ
SOLID原則とは?
SOLID原則の中身
- 単一責任の原則
- オープン・クローズドの原則
- リスコフの置換原則
- 依存関係逆転の原則
- インターフェース分離の原則
まとめ
依存関係逆転の原則
上位モジュールは
下位のモジュールに
依存してはならない
どちらのモジュールも「抽象」に
依存すべきである
どういうこと?
上位クラスが方針を決め、
下位クラスがその方針に従う
悪い例
Playerクラス PlayerのHPを記憶
するクラス
何が悪いの?
・下位クラスに依存してしまっている
・他に記憶させたいものが
出てきた時にif文が増える
改善
Playerクラス 記憶するインター
フェース
下位クラスに依存せずに
抽象クラスに依存している
アジェンダ
SOLID原則とは?
SOLID原則の中身
- 単一責任の原則
- オープン・クローズドの原則
- リスコフの置換原則
- 依存関係逆転の原則
- インターフェース分離の原則
まとめ
インターフェース分離の原則
クライアントが利用しない
メソッドへの依存を
強制してはならない
どういうこと?
インターフェースは
シンプルにする
悪い例
Playerインターフェース
何が悪いの?
Playerインターフェース
・このインターフェイスを継承したクラスの
メソッドを変更した場合、他のメソッドも
変更しなければならない可能性がある
改善
当たったときのインターフェース
インターフェイスの実装は
必要最低限にする
アジェンダ
SOLID原則とは?
SOLID原則の中身
- 単一責任の原則
- オープン・クローズドの原則
- リスコフの置換原則
- 依存関係逆転の原則
- インターフェース分離の原則
まとめ
まとめ
SOLID原則はあくまで「原則」
なので、臨機応変に使用しよう
ご清聴ありがとうございました

Contenu connexe

Tendances

オブジェクト指向できていますか?
オブジェクト指向できていますか?オブジェクト指向できていますか?
オブジェクト指向できていますか?
Moriharu Ohzu
 
日本語テストメソッドについて
日本語テストメソッドについて日本語テストメソッドについて
日本語テストメソッドについて
kumake
 

Tendances (20)

Test Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるかTest Yourself - テストを書くと何がどう変わるか
Test Yourself - テストを書くと何がどう変わるか
 
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
 
Lean Customer Development と顧客インタビュー (技術者/研究者発スタートアップのためのリーンスタートアップ)
Lean Customer Development と顧客インタビュー (技術者/研究者発スタートアップのためのリーンスタートアップ)Lean Customer Development と顧客インタビュー (技術者/研究者発スタートアップのためのリーンスタートアップ)
Lean Customer Development と顧客インタビュー (技術者/研究者発スタートアップのためのリーンスタートアップ)
 
オブジェクト指向できていますか?
オブジェクト指向できていますか?オブジェクト指向できていますか?
オブジェクト指向できていますか?
 
REST API のコツ
REST API のコツREST API のコツ
REST API のコツ
 
ドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみようドメイン駆動設計 ( DDD ) をやってみよう
ドメイン駆動設計 ( DDD ) をやってみよう
 
やはりお前らのMVCは間違っている
やはりお前らのMVCは間違っているやはりお前らのMVCは間違っている
やはりお前らのMVCは間違っている
 
golang.tokyo #6 (in Japanese)
golang.tokyo #6 (in Japanese)golang.tokyo #6 (in Japanese)
golang.tokyo #6 (in Japanese)
 
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove事業が対峙する現実からエンジニアリングを俯瞰する #devlove
事業が対峙する現実からエンジニアリングを俯瞰する #devlove
 
日本語テストメソッドについて
日本語テストメソッドについて日本語テストメソッドについて
日本語テストメソッドについて
 
「速」を落とさないコードレビュー
「速」を落とさないコードレビュー「速」を落とさないコードレビュー
「速」を落とさないコードレビュー
 
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
 
イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)イミュータブルデータモデル(世代編)
イミュータブルデータモデル(世代編)
 
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向プログラミングのためのモデリング入門
 
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptxネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
ネットストーカー御用達OSINTツールBlackBirdを触ってみた.pptx
 
それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?それはYAGNIか? それとも思考停止か?
それはYAGNIか? それとも思考停止か?
 
テストとリファクタリングに関する深い方法論 #wewlc_jp
テストとリファクタリングに関する深い方法論 #wewlc_jpテストとリファクタリングに関する深い方法論 #wewlc_jp
テストとリファクタリングに関する深い方法論 #wewlc_jp
 
Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.
Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.
Redmineチューニングの実際と限界(旧資料) - Redmine performance tuning(old), See Below.
 
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるなテスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
 
老害について
老害について老害について
老害について
 

SOLID原則とは