Principles of Object-Oriented Design1. ボブおじさんから学んだ
オブジェクト指向設計の原則
RejectTalks 2007 Edition
Entry
[accept] [reject]
(株)永和システムマネジメント
RejectTalks
Lightning Talks
伊藤 浩一
http://www.edit.ne.jp/~koic/ 4. クラス設計の原則
SRP: The Single Responsibility Principle
•
OCP: The Open-Closed Principle
•
LSP: The Liskov Substitution Principle
•
DIP: The Dependency Inversion Principle
•
ISP: The Interface Segregation Principle
• 5. The Single Responsibility Principle
(単一責任の原則:SRP)
• 『クラスを変更する理由は1つ以上存在してはならな
い』
– Simple is NOT Naive
• 役割 = 変更理由
• 楽観的ロックのバージョン管理システム
– JavaやRailsだと1クラス1ファイルが基本
– タスク分割
• 機能ごとに分割されることが多いのでは?
– ファイルの競合が発生したらSRPに反していないかクラス
設計を見直す機会
• 同じ変更理由か?異なる変更理由か? 6. The Open-Closed Principle
(オープン・クローズドの原則:OCP)
• 『ソフトウェアの構成要素は拡張に対して開いて、修
正に対して閉じていなければならない』
(Bertrand Meyer氏)
• 「実は,デザインパターンのうちの多くは OCP を満た
すために用意されたものと考えることができるので
す.」 (石井 勝さん)
– http://www.morijp.com/masarl/homepage3.nifty.com
/masarl/article/dp-ocp-2.html
• 抽象化設計の基本
Client Interface
Client Server Client
Server 7. The Liskov Substitution Principle
(リスコフの置換原則:LSP)
• 『派生型はその基本型と置換可能でなければ
ならない』 (Barbara Liskov氏)
• 続きはWebで
DbC (Design by Contract)
とも関係する
Wikipedia―リスコフの置換原則 8. The Dependency Inversion Principle
(依存関係逆転の原則:DIP)
• 『抽象に依存せよ』
• 依存性逆転を起こす”伝家の宝刀”
– 矢印(知っている方向)の逆転
• Hollywood Principle “Don’t call us, we’ll call you”
– IoC、Dependency Injection、Layered Architecture
• インターフェース(抽象)重要
Policy
Policy Service Interface
Policy
Policy Layer
Layer Mechanism
Mechanism Service
Mechanism
Interface
Mechanism
Layer
Layer
Utility
Utility
Layer
Utility
Layer 9. The Interface Segregation Principle
(インタフェース分離の原則:ISP)
• 『クライアントに、クライアントが利用しないメ
ソッドへの依存を強制してはならない』
• クライアントの分離 = インタフェースの分離
– クライアント主導でインタフェースを導出する
• 「インタフェースに対してプログラミングするのであって、
実装に対してプログラミングするのではない」 (GoF)
– TDDは設計手法
• テストコードが最初のクライアント
• テストコードが必要とするコードを書く 10. パッケージ設計の原則
• 高凝集(High cohesion)に関する原則
– REP: Reuse-Release Equivalency Principle
– CRP: Common Reuse Principle
– CCP: Common Closure Principle
• 疎結合(Low coupling)に関する原則
– ADP: Acyclic Dependencies Principle
– SDP: Stable Dependencies Principle
– SAP: Stable Abstractions Principle 12. Reuse-Release Equivalency Principle
(再利用・リリース等価の原則:REP)
• 『再利用の単位とリリースの単位は等価になる』
• リリースすることでクライアントに利用される
– 再利用可能な利用と再利用不可能な利用
– すべて再利用可能か?すべて再利用不可能か?
• 0か1
• 混ぜるな危険
• ソフトウェア利用者のサポート
– トラッキングシステムという環境
– チェンジログやバージョニング 13. Common Reuse Principle
(全再利用の原則:CRP)
• 『パッケージに含まれるクラスは、すべて一緒
に再利用される』
– 再利用の単位はクラスではなくパッケージ
• 一緒に使われる傾向のあるクラスは同じパッ
ケージに、強い関連性を持たないクラスは別
のパッケージに含む
– 再配布したときにはパッケージの粒度で再評価さ
れる
– 混ぜるな危険 14. Common Closure Principle
(閉鎖性共通の原則:CCP)
• 『パッケージに含まれるクラスは、みな同じ種
類の変更に対して閉じているべきである』
– 誤解を恐れずに云うならば“SRP”のパッケージ版
• 同じの変更理由で修正されるクラスは1つの
パッケージにまとめる
– 変更理由が少なければ再評価、再リリースする
パッケージも少なくあるべき
• 混ぜるな危険 15. The Acyclic Dependencies Principle
(非循環依存関係の原則:ADP)
• 『パッケージ依存グラフに循環を持ち込んでは
ならない』
– リリース可能なパッケージ分割をする
• 依存サイクルが発生したときの道はふたつ
– 循環依存しているパッケージが依存する、新しい
パッケージを導入する
– 伝家の宝刀”DIP”で依存関係を逆転する
MyDialogs MyApplication
MyDialogs MyApplication
X Server
Y
X Y X
伝家の宝刀”DIP”によるパッケージ依存の逆転 16. The Stable Dependencies Principle
(安定依存の原則:SDP)
• 『安定する方向に依存せよ』
• システムは変化し続ける
– 安定したパッケージと不安定なパッケージがある
• StableとFlexible
• “不安定”という音の響き
– ”不安定”は良くない?
• 設計は完全に固定できないため、不安定性を許す仕組
みが必要
• 不安定なパッケージが悪いのではなく、不安定なパッ
ケージに依存することが悪いこと 18. 4q!
• ご清聴ありがとうございました。
– オブジェクト指向設計の原則を纏めてくれたボブお
じさん、
– (いつもながら原書を積んでいた私に)良質の和
訳を送り出してくれた瀬谷 啓介さん、
– そして私にオブジェクト指向設計の原則との出会
いをくれた、まさーるさんに感謝します。