ボブおじさんから学んだ
                          オブジェクト指向設計の原則
                                         RejectTalks 2007 Edition


  ...
大事なことは最初に
• 開発の現場 vol.11(2008年1月発売)に
  『保守プロジェクトとデベロッパーテスティング』
  という記事を寄稿しました
 – 『Web 2.0ビギナーズバイブル』をあわせてお買い
   求めください
• 今日...
オブジェクト指向設計の原則
• Robert C. Martin(a.k.a Uncle Bob)著
  『Agile Software Development』より
  – 邦訳 『オブジェクト指向設計の奥義』
クラス設計の原則
    SRP: The Single Responsibility Principle
•
    OCP: The Open-Closed Principle
•
    LSP: The Liskov Substitut...
The Single Responsibility Principle
     (単一責任の原則:SRP)
• 『クラスを変更する理由は1つ以上存在してはならな
  い』
 – Simple is NOT Naive
• 役割 = 変更理由
...
The Open-Closed Principle
 (オープン・クローズドの原則:OCP)
• 『ソフトウェアの構成要素は拡張に対して開いて、修
  正に対して閉じていなければならない』
  (Bertrand Meyer氏)
• 「実は,デ...
The Liskov Substitution Principle
         (リスコフの置換原則:LSP)
  • 『派生型はその基本型と置換可能でなければ
    ならない』 (Barbara Liskov氏)
  • 続きはWeb...
The Dependency Inversion Principle
    (依存関係逆転の原則:DIP)
• 『抽象に依存せよ』
• 依存性逆転を起こす”伝家の宝刀”
  – 矢印(知っている方向)の逆転
          • Holly...
The Interface Segregation Principle
  (インタフェース分離の原則:ISP)
• 『クライアントに、クライアントが利用しないメ
  ソッドへの依存を強制してはならない』
• クライアントの分離 = インタフェ...
パッケージ設計の原則
• 高凝集(High cohesion)に関する原則
 – REP: Reuse-Release Equivalency Principle
 – CRP: Common Reuse Principle
 – CCP: C...
高凝集と疎結合
• 一枚のコインの表と裏
Reuse-Release Equivalency Principle
 (再利用・リリース等価の原則:REP)
• 『再利用の単位とリリースの単位は等価になる』
• リリースすることでクライアントに利用される
  – 再利用可能な利用と再利用...
Common Reuse Principle
   (全再利用の原則:CRP)
• 『パッケージに含まれるクラスは、すべて一緒
  に再利用される』
 – 再利用の単位はクラスではなくパッケージ
• 一緒に使われる傾向のあるクラスは同じパッ
 ...
Common Closure Principle
   (閉鎖性共通の原則:CCP)
• 『パッケージに含まれるクラスは、みな同じ種
  類の変更に対して閉じているべきである』
 – 誤解を恐れずに云うならば“SRP”のパッケージ版
• 同じの...
The Acyclic Dependencies Principle
  (非循環依存関係の原則:ADP)
• 『パッケージ依存グラフに循環を持ち込んでは
  ならない』
 – リリース可能なパッケージ分割をする
• 依存サイクルが発生したとき...
The Stable Dependencies Principle
     (安定依存の原則:SDP)
• 『安定する方向に依存せよ』
• システムは変化し続ける
 – 安定したパッケージと不安定なパッケージがある
   • StableとF...
Stable Abstractions Principle
(安定度・抽象度等価の原則:SAP)
• 『パッケージの抽象度と安定度は同程度でな
  ければならない』
• 安定したパッケージは抽象度を高く、不安定な
  パッケージは具体的にする
...
4q!
• ご清聴ありがとうございました。
 – オブジェクト指向設計の原則を纏めてくれたボブお
   じさん、
 – (いつもながら原書を積んでいた私に)良質の和
   訳を送り出してくれた瀬谷 啓介さん、
 – そして私にオブジェクト指向設...
Upcoming SlideShare
Loading in …5
×

Principles of Object-Oriented Design

5,128 views
5,006 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,128
On SlideShare
0
From Embeds
0
Number of Embeds
49
Actions
Shares
0
Downloads
52
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Principles of Object-Oriented Design

  1. 1. ボブおじさんから学んだ オブジェクト指向設計の原則 RejectTalks 2007 Edition Entry [accept] [reject] (株)永和システムマネジメント RejectTalks Lightning Talks 伊藤 浩一 http://www.edit.ne.jp/~koic/
  2. 2. 大事なことは最初に • 開発の現場 vol.11(2008年1月発売)に 『保守プロジェクトとデベロッパーテスティング』 という記事を寄稿しました – 『Web 2.0ビギナーズバイブル』をあわせてお買い 求めください • 今日はオブジェクト指向設計の原則という これらの記事に書いていないお話しをします
  3. 3. オブジェクト指向設計の原則 • Robert C. Martin(a.k.a Uncle Bob)著 『Agile Software Development』より – 邦訳 『オブジェクト指向設計の奥義』
  4. 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. 5. The Single Responsibility Principle (単一責任の原則:SRP) • 『クラスを変更する理由は1つ以上存在してはならな い』 – Simple is NOT Naive • 役割 = 変更理由 • 楽観的ロックのバージョン管理システム – JavaやRailsだと1クラス1ファイルが基本 – タスク分割 • 機能ごとに分割されることが多いのでは? – ファイルの競合が発生したらSRPに反していないかクラス 設計を見直す機会 • 同じ変更理由か?異なる変更理由か?
  6. 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. 7. The Liskov Substitution Principle (リスコフの置換原則:LSP) • 『派生型はその基本型と置換可能でなければ ならない』 (Barbara Liskov氏) • 続きはWebで DbC (Design by Contract) とも関係する Wikipedia―リスコフの置換原則
  8. 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. 9. The Interface Segregation Principle (インタフェース分離の原則:ISP) • 『クライアントに、クライアントが利用しないメ ソッドへの依存を強制してはならない』 • クライアントの分離 = インタフェースの分離 – クライアント主導でインタフェースを導出する • 「インタフェースに対してプログラミングするのであって、 実装に対してプログラミングするのではない」 (GoF) – TDDは設計手法 • テストコードが最初のクライアント • テストコードが必要とするコードを書く
  10. 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. 11. 高凝集と疎結合 • 一枚のコインの表と裏
  12. 12. Reuse-Release Equivalency Principle (再利用・リリース等価の原則:REP) • 『再利用の単位とリリースの単位は等価になる』 • リリースすることでクライアントに利用される – 再利用可能な利用と再利用不可能な利用 – すべて再利用可能か?すべて再利用不可能か? • 0か1 • 混ぜるな危険 • ソフトウェア利用者のサポート – トラッキングシステムという環境 – チェンジログやバージョニング
  13. 13. Common Reuse Principle (全再利用の原則:CRP) • 『パッケージに含まれるクラスは、すべて一緒 に再利用される』 – 再利用の単位はクラスではなくパッケージ • 一緒に使われる傾向のあるクラスは同じパッ ケージに、強い関連性を持たないクラスは別 のパッケージに含む – 再配布したときにはパッケージの粒度で再評価さ れる – 混ぜるな危険
  14. 14. Common Closure Principle (閉鎖性共通の原則:CCP) • 『パッケージに含まれるクラスは、みな同じ種 類の変更に対して閉じているべきである』 – 誤解を恐れずに云うならば“SRP”のパッケージ版 • 同じの変更理由で修正されるクラスは1つの パッケージにまとめる – 変更理由が少なければ再評価、再リリースする パッケージも少なくあるべき • 混ぜるな危険
  15. 15. The Acyclic Dependencies Principle (非循環依存関係の原則:ADP) • 『パッケージ依存グラフに循環を持ち込んでは ならない』 – リリース可能なパッケージ分割をする • 依存サイクルが発生したときの道はふたつ – 循環依存しているパッケージが依存する、新しい パッケージを導入する – 伝家の宝刀”DIP”で依存関係を逆転する MyDialogs MyApplication MyDialogs MyApplication X Server Y X Y X 伝家の宝刀”DIP”によるパッケージ依存の逆転
  16. 16. The Stable Dependencies Principle (安定依存の原則:SDP) • 『安定する方向に依存せよ』 • システムは変化し続ける – 安定したパッケージと不安定なパッケージがある • StableとFlexible • “不安定”という音の響き – ”不安定”は良くない? • 設計は完全に固定できないため、不安定性を許す仕組 みが必要 • 不安定なパッケージが悪いのではなく、不安定なパッ ケージに依存することが悪いこと
  17. 17. Stable Abstractions Principle (安定度・抽象度等価の原則:SAP) • 『パッケージの抽象度と安定度は同程度でな ければならない』 • 安定したパッケージは抽象度を高く、不安定な パッケージは具体的にする – 安定したパッケージは抽象クラス中心で構成する • 柔軟さ、設計の自由さを残す – 不安定なパッケージは具象クラス中心で構成する • 具体的なコードを変更可能にする
  18. 18. 4q! • ご清聴ありがとうございました。 – オブジェクト指向設計の原則を纏めてくれたボブお じさん、 – (いつもながら原書を積んでいた私に)良質の和 訳を送り出してくれた瀬谷 啓介さん、 – そして私にオブジェクト指向設計の原則との出会 いをくれた、まさーるさんに感謝します。

×