Microsoft PowerPoint - reject_talks_2007.ppt

Size: px

Start display at page:

Download "Microsoft PowerPoint - reject_talks_2007.ppt"

つねたけあると
6 years ago
Views:

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

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) クラスを変更する理由は 1 つ以上存在してはならない Simple is NOT Naive 役割 = 変更理由楽観的ロックのバージョン管理システム Java や Rails だと 1 クラス 1 ファイルが基本タスク分割機能ごとに分割されることが多いのでは? ファイルの競合が発生したら SRP に反していないかクラス設計を見直す機会同じ変更理由か? 異なる変更理由か?

6 The Open-Closed Principle ( オープンクローズドの原則 :OCP) ソフトウェアの構成要素は拡張に対して開いて修正に対して閉じていなければならない (Bertrand Meyer 氏 ) 実は, デザインパターンのうちの多くは OCP を満たすために用意されたものと考えることができるのです. ( 石井勝さん ) /masarl/article/dp-ocp-2.html 抽象化設計の基本 Client Server Client Client Interface 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 Layer Mechanism Layer Utility Layer Policy Layer Mechanism Utility Policy Service Interface Mechanism Layer Mechanism Service Interface 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) 再利用の単位とリリースの単位は等価になるリリースすることでクライアントに利用される再利用可能な利用と再利用不可能な利用すべて再利用可能か? すべて再利用不可能か? 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 X Y X Y 伝家の宝刀 DIP によるパッケージ依存の逆転

16 The Stable Dependencies Principle ( 安定依存の原則 :SDP) 安定する方向に依存せよシステムは変化し続ける安定したパッケージと不安定なパッケージがある Stable と Flexible 不安定という音の響き不安定は良くない? 設計は完全に固定できないため不安定性を許す仕組みが必要不安定なパッケージが悪いのではなく不安定なパッケージに依存することが悪いこと

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

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

デザインパターン第一章「生成《

デザインパターン第一章「生成《変化に強いプログラミング ~ デザインパターン第一章生成 ~ 梅林 ( 高田明宏 )@ わんくま同盟デザインパターンとは何か (1) デザインパターンの定義ソフトウェア開発におけるデザインパターンとは過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し名前をつけ再利用しやすいように特定の規約に従ってカタログ化したもの (Wikipedia) 参考書籍オブジェクト指向における再利用のためのデザインパターン