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

2019年4月2日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は必要か
旅は終わらない