本書は、JavaやC#を知っている読者を対象に、オブジェクト指向の基礎と応用を解説するものです。再利用ができ、堅牢で、拡張可能な本格的オブジェクト指向ソフトウェアを分析し、設計し、書くことができるようになることを本書の目標としています。柔軟なアプリケーションを作るためにカプセル化や委譲など、オブジェクト指向の原則を取り入れます。またコードの再利用を促すための開放閉鎖原則（OCP）や単一責任原則（SRP）適用について解説します。オブジェクト指向の原則、デザインパターン、さまざまな開発手法を、オブジェクト指向分析設計プロジェクトのライフサイクルに適合させる方法も学びます。
複雑な概念を脳に記憶させるため、図やイラスト、また登場人物に物語を持たせるなどさまざまな工夫を施した本書は、最短の時間で最大の効果をあげることができます。
Head Firstオブジェクト指向分析設計
―頭とからだで覚えるオブジェクト指向の基本
Brett McLaughlin, Gary Pollice, David West 著、長瀬 嘉秀、永田 渉 監訳、株式会社テクノロジックアート 訳
![[cover photo]](https://www.oreilly.co.jp/books/images/picture_large978-4-87311-349-4.jpeg)
- TOPICS
- Head First , Programming
- 発行年月日
- 2007年12月
- PRINT LENGTH
- 636
- ISBN
- 978-4-87311-349-4
- 原書
- Head First Object-Oriented Analysis and Design
- FORMAT
目次
序章 この本の使い方 この本の対象読者 読者の考えは理解しています メタ認知 脳を服従させる方法 注意事項 テクニカルチーム 謝辞 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とクラス図 継承 ポリモーフィズム カプセル化 重要ポイント