Head First オブジェクト指向分析設計

2020年1月21日


Head Firstオブジェクト指向分析設計 ―頭とからだで覚えるオブジェクト指向の基本


オライリー・ジャパン


著者:Brett McLaughlin、Gary Pollice、David West
監訳:長瀬嘉秀、永田渉
訳者:株式会社テクノロジックアート


序章 この本の使い方
この本の対象読者
読者の考えは理解しています
メタ認知
脳を服従させる方法
注意事項
テクニカルチーム
謝辞

1章 よく設計されたアプリケーションは心を動かす
ロックンロールは永遠
Rickの輝かしい新アプリケーション
最初に変更すべきこと
素晴らしいソフトウェアが持つ意味
素晴らしいソフトウェアへの3つのステップ
はじめは機能に着目
テスト実行
問題の発見
分析
オブジェクト指向の基本原則の適用
1回目の設計、2回目の設計
アプリケーションの変更容易性
変動するものをカプセル化する
委譲
最後のテスト実行(そして再利用可能なアプリケーション)
オブジェクト指向分析設計とは素晴らしいソフトウェアを作成するための方法
重要ポイント

2章 要件収集
新しいプログラミングの仕事
テスト実行
誤った使用
要件とは正確には何なのか
要件一覧の作成
転ばぬ先の杖
システムの問題に対処する代替パス
ユースケースの(再)紹介
ユースケースの3要素
要件とユースケースの照合
システムは現実世界で動作することが必要
ハッピーパスとの出会い
オブジェクト指向分析設計のツールボックス

3章 要件変更
英雄だ!
生贄だ!
ソフトウェア分析設計において唯一不変であること
オプションのパスか、代替パスか、区別が付くか
必要なのは、わかりやすいユースケース
開始から終了まで、1つのシナリオ
代替パスの告白
要件一覧の完成
コードの重複は、絶対避けるべき
最後のテスト実行
自分独自の設計原則
オブジェクト指向分析設計のツールボックス

4章 分析
犬が1匹、2匹、3匹、4匹……
ソフトウェアが置かれている状況
問題の識別
解決策の計画
2人のコーダーの話
委譲
疎結合アプリケーションの力
ユースケース内の名詞に着目
よい分析からよいクラスへ
クラス図の詳細
クラス図に含まれない内容
重要ポイント

5章前編 よい設計=柔軟なソフトウェア
Rickのギターの拡張
抽象クラス
クラス図の詳細(ふたたび)
UMLチェックシート
設計上の問題に関する兆候
素晴らしいソフトウェアへの3つのステップ(ふたたび)

5章幕あい OO CATASTROPHE

5章後編 よい設計=柔軟なソフトウェア
Rickの検索ツールに戻る
search()メソッドの詳細
分析を行う利点
振る舞いごとにクラスを作成
設計(決断)の死
設計上の間違った決断を正す
Rickのソフトウェアにおける「二重カプセル化」
失敗を恐れない
Rickの柔軟なアプリケーション
よい設計のソフトウェアのテスト実行
Rickのソフトウェアにおける変更の容易性
変更容易性への挑戦
高凝集のクラスは1つのことだけを行う
設計/凝集度ライフサイクル
素晴らしいソフトウェアは十分によい
オブジェクト指向分析設計のツールボックス

6章 本当に大きな問題の解決
大きな問題の解決
大きな問題の見方
要件とユースケースは適切な開始場所
共通性と変動性
フィーチャの理解
フィーチャと要件の「違い」
必ずしも全体像把握に役立たないユースケース
ユースケース図
小さなアクター
アクターは人でもある(必ずしもそうではないが)
ドメイン分析
分割統治
本当の顧客は誰かを忘れてはいけない
デザインパターンとは何か、どのように使用するのか
オブジェクト指向分析設計(と少しの常識)の力
オブジェクト指向分析設計のツールボックス

7章 アーキテクチャ
少し大変だと思えること
アーキテクチャの必要性
機能から開始
アークテクチャ的な意味とは何か
アーキテクチャに関する3つの質問
リスク軽減
リスク軽減に役立つシナリオ
一度に1つのフィーチャに着目
アーキテクチャとは設計の構造
共通性(ふたたび)
共通性分析:柔軟なソフトウェアへの道
意味は顧客に尋ねる
素晴らしいソフトウェア作成に役立つリスク軽減
重要ポイント

8章 設計の原則
設計原則の要約
開放閉鎖原則(OCP)
OCPステップバイステップ
繰返禁止原則(DRY)
1つの要件を1箇所にまとめるのがDRY
単一責任原則(SRP)
複数責任の発見
複数責任から単一責任への移行
リスコフ置換原則(LSP)
サブクラスの誤用:継承の誤用例
LSPで発見される継承の問題
サブタイプは基底タイプと置換可能でなければいけない
LSPの侵害により混乱したコード
他のクラスへの機能の委譲
コンポジションを用いて、他のクラスから振る舞いを組み立てる
集約:突然終了することのないコンポジション
集約対コンポジション
ひとつの選択肢にすぎない継承
重要ポイント
オブジェクト指向分析設計のツールボックス

9章 イテレーションとテスト
ツールボックスの補充
イテレーティブな素晴らしいソフトウェア作成
機能を深めるイテレーション:2つの基本的な選択肢
フィーチャ駆動開発
ユースケース駆動開発
2つの開発手法
フィーチャの分析
テストシナリオの作成
テスト駆動開発
共通性分析の洗練
共通性の重視
カプセル化の重視
テストと設計のマッチング
テストケースの詳細
顧客への証明
契約によるプログラミング
契約によるプログラミングには信頼が欠かせない
防御的プログラミング
小さな機能群へのアプリケーションの分割
重要ポイント
オブジェクト指向分析設計のツールボックス

10章 オブジェクト指向分析設計のライフサイクル
オブジェクト指向分析設計によるソフトウェア開発
Objectvilleの地下鉄問題
Objectvilleの地下鉄路線図
フィーチャ一覧
ユースケースは使用方法を反映し、フィーチャは機能を反映する
イテレーションの開始
地下鉄表現の詳細
Lineクラスを使うか、使わないか
ObjectvilleのSubwayクラスで重要な点
クラスの保護
休憩
要件フェーズに戻る
コードに着目してから、顧客に着目する
イテレーションによる問題の容易化
経路の外観
自分でObjectvilleを調べる
イテレーション3は必要か
旅は終わらない

付録I 残っている作業
第1位 IS-AとHAS-A
第2位 ユースケースの書式
第3位 アンチパターン
第4位 CRCカード
第5位 メトリックス
第6位 シーケンス図
第7位 ステートマシン図
第8位 ユニットテスト
第9位 コーディング規約と判読可能なコード
第10位 リファクタリング

付録II Objectvilleへようこそ
UMLとクラス図
継承
ポリモーフィズム
カプセル化
重要ポイント

書籍目次

Posted by shi-n