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

―頭とからだで覚えるオブジェクト指向の基本

[cover photo]
TOPICS
Head First , Programming
発行年月日
PRINT LENGTH
636
ISBN
978-4-87311-349-4
原書
Head First Object-Oriented Analysis and Design
FORMAT
PDF
Ebook
4,400円
Ebookを購入する

本書は、JavaやC#を知っている読者を対象に、オブジェクト指向の基礎と応用を解説するものです。再利用ができ、堅牢で、拡張可能な本格的オブジェクト指向ソフトウェアを分析し、設計し、書くことができるようになることを本書の目標としています。柔軟なアプリケーションを作るためにカプセル化や委譲など、オブジェクト指向の原則を取り入れます。またコードの再利用を促すための開放閉鎖原則(OCP)や単一責任原則(SRP)適用について解説します。オブジェクト指向の原則、デザインパターン、さまざまな開発手法を、オブジェクト指向分析設計プロジェクトのライフサイクルに適合させる方法も学びます。
複雑な概念を脳に記憶させるため、図やイラスト、また登場人物に物語を持たせるなどさまざまな工夫を施した本書は、最短の時間で最大の効果をあげることができます。

目次

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

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とクラス図
	継承
	ポリモーフィズム
	カプセル化
	重要ポイント