magazine.gif教養としてのプログラミング講座

序章 この本の使い方

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

1章 よく設計されたアプリケーションは心を動かす

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

2章 要件収集

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

3章 要件変更

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

4章 分析

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

5章前編 よい設計=柔軟なソフトウェア

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

5章幕あい OO CATASTROPHE

  • Objectvilleで一番人気のクイズ番組

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