1. ボブおじさんから学んだ
オブジェクト指向設計の原則
RejectTalks 2007 Edition
Entry
[accept] [reject]
(株)永和システムマネジメント
RejectTalks
Lightning Talks
伊藤 浩一
http://www.edit.ne.jp/~koic/

2. 大事なことは最初に
• 開発の現場 vol.11（2008年1月発売）に
『保守プロジェクトとデベロッパーテスティング』
という記事を寄稿しました
– 『Web 2.0ビギナーズバイブル』をあわせてお買い
求めください
• 今日はオブジェクト指向設計の原則という
これらの記事に書いていないお話しをします

3. オブジェクト指向設計の原則
• Robert C. Martin(a.k.a Uncle Bob)著
『Agile Software Development』より
– 邦訳 『オブジェクト指向設計の奥義』

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）
• 『クラスを変更する理由は１つ以上存在してはならな
い』
– 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

11. 高凝集と疎結合
• 一枚のコインの表と裏

12. Reuse-Release Equivalency Principle
（再利用・リリース等価の原則：REP）
• 『再利用の単位とリリースの単位は等価になる』
• リリースすることでクライアントに利用される
– 再利用可能な利用と再利用不可能な利用
– すべて再利用可能か？すべて再利用不可能か？
• ０か１
• 混ぜるな危険
• ソフトウェア利用者のサポート
– トラッキングシステムという環境
– チェンジログやバージョニング

13. Common Reuse Principle
（全再利用の原則：CRP）
• 『パッケージに含まれるクラスは、すべて一緒
に再利用される』
– 再利用の単位はクラスではなくパッケージ
• 一緒に使われる傾向のあるクラスは同じパッ
ケージに、強い関連性を持たないクラスは別
のパッケージに含む
– 再配布したときにはパッケージの粒度で再評価さ
れる
– 混ぜるな危険

14. Common Closure Principle
（閉鎖性共通の原則：CCP）
• 『パッケージに含まれるクラスは、みな同じ種
類の変更に対して閉じているべきである』
– 誤解を恐れずに云うならば“SRP”のパッケージ版
• 同じの変更理由で修正されるクラスは１つの
パッケージにまとめる
– 変更理由が少なければ再評価、再リリースする
パッケージも少なくあるべき
• 混ぜるな危険

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
• “不安定”という音の響き
– ”不安定”は良くない？
• 設計は完全に固定できないため、不安定性を許す仕組
みが必要
• 不安定なパッケージが悪いのではなく、不安定なパッ
ケージに依存することが悪いこと

17. Stable Abstractions Principle
（安定度・抽象度等価の原則：SAP）
• 『パッケージの抽象度と安定度は同程度でな
ければならない』
• 安定したパッケージは抽象度を高く、不安定な
パッケージは具体的にする
– 安定したパッケージは抽象クラス中心で構成する
• 柔軟さ、設計の自由さを残す
– 不安定なパッケージは具象クラス中心で構成する
• 具体的なコードを変更可能にする

18. 4q!
• ご清聴ありがとうございました。
– オブジェクト指向設計の原則を纏めてくれたボブお
じさん、
– （いつもながら原書を積んでいた私に）良質の和
訳を送り出してくれた瀬谷 啓介さん、
– そして私にオブジェクト指向設計の原則との出会
いをくれた、まさーるさんに感謝します。