More Related Content
Similar to オブジェクト指向設計の原則 (20)
More from Toru Koido (13)
オブジェクト指向設計の原則
- 2. 自己紹介 仕事 パッケージベンダーで、パッケージを開発 具体的な作業内容 開発のガイドラインを作る 開発プロセスを設計する 開発プロセスを支える環境を構築し、運用する 各種ツールの選択や開発 ビルド環境の整備、各種管理ツールの整備 ソフトウェア・アーキテクチャの決定する 基盤フレームワークの設計と実装 基盤の共通ライブラリの設計と実装 開発上のいろいろな相談を受ける 今日の目的 オブジェクト指向における設計の基本原則やデザインパターンなどについて、良い設計という観点で議論したいと思います 特に、アーキテクチャと設計の関係について、会場のみなさんと考えたいと思います 2
- 19. ソフトウェアアーキテクチャの定義 ソフトウェアアーキテクチャの定義 複数の定義が必要 複数の角度からの表現を組み合わせて定義を行う ソフトウェア開発のビジョンを実現するために必要なソフトウェア構造 構造化原則 抽象的な構造やガイドライン 概念的な構造（モデリング） ANSI/IEEE Std 1471-2000 構成要素を統合したシステムの基本的な構造，構成要素の相互および構成要素と環境間の関係，そしてシステム設計と発展を導く方針 全体の分け方と、分けた部分をどのように関係づけるか 19
- 21. アーキテクチャの複数のビュー ビューポイントとは ステークホルダの関心事に応じた視点 ビューとは 複数の関連した視点（ビューポイント）によって、アーキテクチャを記述するものがビューである ４つのビュー 論理ビュー システムが必要とされている機能を実現する、論理的な構造 実行ビュー 実行時のプロセスやタスクやスレッドといった実行時の単位の構造 開発ビュー システムが開発時のファイル等を単位とした構造 配置ビュー システムをどのようなマシン上で動作させ、各プロセスがどのマシン（CPU)上に配置されるか等を表した構造 21
- 30. 悪い設計の兆候 硬さ 変化しにくいシステム １つの変更が全体に影響し、多くの変更が必要になる もろさ １つの変更で、論理的には関連のない箇所まで正常動作しなくなる 扱いにくさ 正しいことをすることが難しいシステム 不透明さ 読みにくく、わかりにくい 不必要な複雑さ 本質的に意味を持たない構造が含まれているシステム 不必要な繰り返し 同じような構造が繰り返し現われ、共通化できる部分がされていない 移植性のなさ 再利用できる部分を切り出すことができない 30
- 31. 良い設計とは（設計品質特性） 正確性 仕様を正しく満たしていること 理解性 設計結果が読みやすく理解しやすいこと 一貫性（統一性） 設計上の個々の概念が首尾一貫して、ぶれがない 変更容易性 機能強化などに伴う変更が容易であること 頑健性 誤った使い方に対して、システムが適切に対処できること システムの一部のバグが全体に波及しないこと 移植性 いろいろなハードウェア、ソフトウェア環境へ容易に移植できること 効率性 実行効率、資源効率ともに十分実用に適応していること 31
- 33. 良いテストの条件 テスト目的が明確である 何をテストするか明確である その目的も明確で、更にひとつであること テストの判定が正しい テストの成功、失敗が正しく判定されている テストを独立して実行することができる テストが他のテストに依存することなく、独立している 繰り返し実行することができる 何度でも繰り返して、テストを実行することができる テストを実行しても、状態が変化しない テストを実行し、成功した場合でも失敗した場合でも、テストを実行する前と後で何も変わらない 33
- 39. 設計の原則 単一責任の原則 SRP（The Single Responsibility Principle） クラスは、１つの役割（責任）だけを持つ １つの理由のみによって、クラスが変更される 役割を単独でテストできる 役割＝変更理由＝テスト単位 凝集（cohesion）と同意 凝集とは、モジュールに含まれる要素間の機能的な結び付き 原則の適用条件 役割の変更が確実に想定される場合 理由なく適応すると、「不必要に複雑な設計」となる 役割をテストする必要がある場合 問題の予兆（もろい設計） ある役割の変更に伴い、本来関係ないと思われる役割のクラスに変更の影響がある 独立したテストが困難なクラスがある 39
- 40. 設計の原則 オープン・クローズドの法則 OCP（The Open-Closed Principle） ソフトウェアの構成要素（クラス、モジュール、関数など）は拡張に対して開いていて、修正に対して閉じていなかればならない 拡張に対して開いているとは 構成要素の振る舞いを拡張できる 修正に対して閉じているとは モジュールの振る舞いを拡張しても、既存のモジュールは変更の必要がない 原則の適用 長く使い続けられるシステムを開発する システムに機能の追加や変更をし、成長させる必要がある 確実でない変化に対応するための準備は 「無意味に複雑な設計」となる 問題の予兆（硬い設計） ちょっとした変更でさえ、修正箇所と依存関係のある全ての箇所を修正する必要がある 機能の追加や修正を行なったときに、それに伴って修正しなければならないif文やswitch文が数多くある コピー＆ペーストで、大量の同じコード存在する 40
- 41. 設計の原則 リスコフの置換原則 LSP（The Liskov Substitution Principle） 派生クラスは、その基本クラスと置換え可能でなければならない 派生クラスは、基本クラスが許可する全てを許可しなければならい 原則の適応条件 基本クラスの派生型を作成する場合 契約による設計 派生クラスは、基本クラスの事前条件より等しいか弱いか 派生クラスは、基本クラスの事後条件より等しいか強いか 単体テストによって契約を明記する 問題の予兆（もろい設計） 派生クラスが増えた場合に基本クラスに変更が必要 派生クラスごとの分岐処理が基本クラスに存在する 基本クラスの機能を派生クラスが無力化する 基本クラスの機能を派生クラスで何もしない動作と置き換える 41
- 42. 設計の原則 依存性逆転の原則 DIP（The Dependency Inversion Principle） 上位モジュールは、下位モジュールに依存してはならない 抽象（目的）に依存させる 実装の詳細に依存させない 原則の適応条件 レイヤ構造によって、システムの複雑性を低くする 変更に耐えられるコードを構築する必要がある コードの保守が想定される 問題の予兆（もろい設計） 下位モジュールの変更が上位モジュールに影響する 42 A A IB B B
- 43. 設計の原則 インターフェイス分離の原則 ISP（The Interface Segregation Principle） クライアントに、クライアント依存しないメソッドへの依存性を強制してはならない インターフェイス内の強い関連があるものをグループ化して分離する 原則の適応条件 変更に強いシステムを開発する 多目的なインターフェイスを目的ごとに分離し、不用意な結びつきを避ける クラス間の依存度を下げて、低結合度を実現する 目的ごとのテストを作成する 問題の予兆（もろい設計） クライアントが利用していないメソッドの変更に影響される インターフェイスの実装クラスの変更が広範囲に影響する インターフェイスが部分的（グループ単位）にしか強い関連を持っていない 43
- 44. テスト駆動開発とは TDDの目的 テスト利用して、良いソフトウェアを開発する TDDの定義（規則） 失敗する自動テストコードを作成するまで、プロダクトコードを書かない コードの重複をなくす TDDのテストコードとは プロダクトコードが実現しなければならないこと プロダクトコードのインターフェイスを洗練させるもの TDDの設計（シンプルな設計） すべてのテストにパスする テストにパスするのに必要なコード 最適な範囲で、最小限の数のクラス 最適な範囲で、最小限の数のメソッド 44
- 58. 参考文献 実践ソフトウェアエンジニアリング ロジャー S・プレスマン 森口 繁一編『ソフトウェア品質管理ガイドブック』日本規格協会(1990) アジャイルソフトウェア開発の奥義 ロバート・C・マーチン 日経ソフトウェア「正しく学ぶソフトウェア設計」 実践UML パターンによる統一プロセスガイド クレーグ・ラーマン UMLによる オブジェクト指向モデリング セルフレビューノート 荒井玲子 UML モデリングの本質 児玉公信 テスト駆動開発入門 ケント・ベッグ ソフトウェアアーキテクチャ 岸知二、野田夏子、深澤良彰 Software Factories ソフトウェアファクトリー Jack Greenfield, Keith Short リファクタリング プログラムの体質改善テクニック Martin Fowler ＩＴ アーキテクチャ・メタモデル セマンティック解説 ITスキル標準 V2 2006 アーキテクトの審美眼 萩原正義 53
Editor's Notes
- これは、概要スライドの 別の例です。
- これは、切り替えを使用した 概要スライドの例です。
