改訂新版 まえがき
はじめに
謝辞
第1章 悪しき構造の弊害を知覚する
1.1 意味不明な命名
1.2 理解を困難にする条件分岐のネスト
1.3 さまざまな悪魔を招きやすいデータクラス
1.3.1 仕様変更時に牙をむく悪魔
1.3.2 重複コード
1.3.3 修正漏れ
1.3.4 可読性低下
1.3.5 未初期化状態（生焼けオブジェクト）
1.3.6 不正値の混入
1.4 悪魔退治の基本
第2章 設計の初歩
2.1 省略せずに意図が伝わる名前を設計する
2.2 変数を使い回さない、目的ごとの変数を用意する
2.3 ベタ書きせず、目的ごとのまとまりでメソッド化
2.4 関係し合うデータとロジックをクラスにまとめる
第3章 カプセル化の基礎―ひとつにまとめる―
3.1 クラス単体で正常に動作するよう設計する
3.1.1 データクラスは単体での正常動作が困難
3.1.2 クラスが自分自身でドメインモデルの完全性を保証する
3.1.3 悪魔に負けない、頑強なクラスの構成要素
3.2 成熟したクラスへ成長させる設計術
3.2.1 コンストラクタで確実に正常値を設定する
3.2.2 計算ロジックをデータ保持側に寄せる
3.2.3 不変で思わぬ動作を防ぐ
3.2.4 変更したい場合は新しいインスタンスを作成する
3.2.5 メソッド引数やローカル変数にもfinalを付け不変にする
3.2.6 「値の渡し間違い」を型で防止する
3.2.7 現実の営みにはないメソッドを追加しないこと
3.3 悪魔退治の効果を検証する
3.4 プログラム構造の問題解決に役立つ設計パターン
3.4.1 完全コンストラクタ
3.4.2 値オブジェクト
Column 種類の異なる言語と本書のノウハウ
第4章 不変の活用―安定動作を構築する―
4.1 再代入
4.1.1 不変にして再代入を防ぐ
4.1.2 引数も不変にする
4.2 可変がもたらす意図せぬ影響
4.2.1 ケース1 可変インスタンスの使い回し
4.2.2 ケース2 関数による可変インスタンスの操作
4.2.3 副作用のデメリット
4.2.4 関数の影響範囲を限定する
4.2.5 不変にして予期せぬ動作を防ぐ
4.3 不変と可変の取り扱い方針
4.3.1 デフォルトは不変に
4.3.2 どんなとき可変にしてよいか
4.3.3 正しく状態変更するメソッドを設計する
4.3.4 コード外とのやりとりは局所化する
第5章 バラバラなデータとロジックをカプセル化する実践技法
5.1 プリミティブ型執着
5.2 staticメソッドの誤用
5.2.1 staticメソッドはインスタンス変数を使えない
5.2.2 インスタンス変数を使う構造につくり変える
5.2.3 インスタンスメソッドのフリしたstaticメソッドに注意
5.2.4 どうしてstaticメソッドが使われてしまうのか
5.2.5 どういうときにstaticメソッドを使えばいいのか
5.3 初期化ロジックの分散
5.3.1 privateコンストラクタ+ファクトリメソッドで目的別初期化
5.3.2 生成ロジックが増えすぎたらファクトリクラスを検討すること
5.4 共通処理クラス（Common・Util）
5.4.1 さまざまなロジックが雑多に置かれがち
5.4.2 オブジェクト指向設計の基本に立ち返ろう
5.4.3 横断的関心事
5.5 結果を返すために引数を使わないこと
Column C#のoutキーワード
5.6 多すぎる引数
5.6.1 意味のある単位ごとにクラス化する
5.7 アクセス連鎖
5.7.1 尋ねるな、命じろ
第6章 関心の分離という考え方―分けて整理する―
6.1 関心の分離の基本
6.1.1 インスタンス変数ごとにクラスを分割する
6.1.2 依存関係を図式化しよう
6.2 目的の違いを見破り、分離しカプセル化する
6.3 インターフェイスと実装の分離
6.3.1 関心の分離がうまくいかない原因
第7章 関心が混ざったコードを分けて整理する実践技法
7.1 ロジックの流用
7.1.1 単一責任の原則
7.1.2 責任が単一になるようクラスを設計する
7.1.3 DRY原則の誤用
Column クソコード動画「共通化の罠」
7.2 継承による関心の混在
7.2.1 スーパークラス依存
7.2.2 継承より委譲
7.2.3 継承による悪しき共通化
Column クソコード動画「継承」
7.3 関心が混在する各種事例と対処方法
7.3.1 なんでもpublic
7.3.2 privateメソッドだらけ
7.3.3 スマートUI
7.3.4 巨大データクラス
7.3.5 トランザクションスクリプトパターン
7.3.6 神クラス
7.3.7 巨大なクラスの対処法
第8章 条件分岐―迷宮化した分岐処理を解きほぐす技法―
8.1 条件分岐のネストによる可読性低下
8.1.1 早期returnでネスト解消
8.1.2 コードの見通しを悪くするelse句も早期returnで解決
8.2 switch文の重複
8.2.1 即座にswitch文を書いてしまう
8.2.2 同じ条件式のswitch文が複数書かれていく
8.2.3 仕様変更時の修正漏れ（case文追加漏れ）
8.2.4 爆発的に増殖するswitch文の重複
8.2.5 条件分岐を一箇所にまとめる
8.2.6 よりスマートにswitch文重複を解消するinterface
8.2.7 interfaceをswitch文重複に応用（ストラテジパターン）
Column クソコード動画「switch文」
8.3 interface設計の考え方を身につけよう
8.3.1 機能を取り換える単位を見つける
8.3.2 結果と入力が同じかどうかを確認する
8.3.3 interfaceを定義する
8.3.4 interfaceを実装したクラスをつくる
8.3.5 機能を取り換えるしくみをつくる
8.4 条件分岐の重複とネスト
8.4.1 ポリシーパターンで条件を集約する
8.5 型の判定で分岐しないこと
8.6 フラグ引数
8.6.1 メソッドを分離する
8.6.2 ストラテジパターンで機能を取り換えられるようにする
8.7 interfaceの使いこなしが中級者への第一歩
第9章 コレクション―ネストを解消する構造化技法―
9.1 自前でコレクション処理を実装してしまう
Column 車輪の再発明
9.2 ループ処理中の条件分岐ネスト
9.2.1 continueで条件分岐のネストを解消する
9.2.2 breakもネスト解消に役立つ
9.3 バラバラなコレクション処理
9.3.1 コレクション処理をカプセル化する
9.3.2 外部へ渡す場合はコレクションを変更できなくする
第10章 設計の健全性をそこなうさまざまな悪魔たち
10.1 デッドコード
10.2 YAGNI原則
10.3 マジックナンバー
10.4 文字列型執着
10.5 グローバル変数
10.5.1 カプセル化とパッケージ依存の設計で影響範囲を小さくする
10.6 null問題
10.6.1 nullを返さない、渡さない、代入しない
10.6.2 null安全
10.7 例外の握り潰し
10.7.1 原因分析困難に陥り開発者を疲弊させる
10.7.2 問題検出時にけたたましく叫ばせる
10.8 設計秩序を破壊するメタプログラミング
10.8.1 リフレクションによるクラス構造および値の変更
10.8.2 型の強みを活かせなくなる、クラス名やメソッド名のハードコード
10.8.3 デメリットを理解し用途を限定すること
10.9 技術駆動パッケージング
10.10 サンプルコードのコピペ
10.11 銀の弾丸
第11章 名前設計―あるべき構造を見破る名前―
11.1 悪魔を呼び寄せる名前
11.1.1 関心事ごとに分割する
11.1.2 関心事にふさわしい命名
11.1.3 大雑把で意味が不明瞭な名前
11.2 名前を設計する―目的駆動名前設計
11.2.1 可能な限り具体的で、意味が狭い、目的に特化した名前を選ぶ
11.2.2 存在駆動ではなく目的駆動で名前を考える
11.2.3 どんな業務目的があるか分析する
11.2.4 声に出して話してみる
11.2.5 利用規約を読んでみる
11.2.6 違う名前に置き換えられないか検討する
11.2.7 関心が分離されているか点検する
11.3 設計時の注意すべきリスク
11.3.1 名前無頓着になるな
11.3.2 仕様変更時の「意味の変化」に警戒
11.3.3 構造改善を妨げるアンカリング効果
11.3.4 会話には登場するがコード上に登場しない名前に注意
11.3.5 名前を知らないものは知覚できない
11.3.6 形容詞で区別しているときはクラス化のチャンス
11.4 意図がわからない名前
11.4.1 技術駆動命名
Column 技術駆動命名を用いる分野もある
11.4.2 ロジック構造をなぞった名前
11.4.3 驚き最小の原則
11.5 構造を歪ませてしまう名前
11.5.1 データクラスになりがちな名前
11.5.2 DTO（Data Transfer Object）
11.5.3 クラスが巨大化する名前
Column クソコード動画「Managerクラス」
11.5.4 文脈よって意味や扱いが異なる名前
11.5.5 連番命名
11.6 名前的に居場所が不自然なメソッド
11.6.1 「動詞+目的語」のメソッド名に注意
11.6.2 可能な限り動詞1語で済む名前にする
11.6.3 不適切な居場所のbooleanメソッド
11.7 名前の省略
11.7.1 意図がわからなくなる省略
11.7.2 基本的に名前は省略しないこと
11.7.3 そのほか省略をどう判断するか
第12章 コメント―保守と変更の正確性を高める書き方―
12.1 退化コメント
12.1.1 コメントは劣化コピーにすぎないことを理解すること
12.1.2 ロジックの挙動をなぞるだけのコメントは退化しやすい
12.2 コメントで命名をごまかす
12.3 目的や仕様変更時の注意点を読み手に伝えること
12.4 コメントのルール まとめ
12.5 ドキュメントコメント
第13章 メソッド（関数） ―良きクラスには良きメソッドあり―
13.1 必ず自身のクラスのインスタンス変数を使うこと
13.2 不変をベースに予期せぬ動作を防ぐ関数にすること
13.3 尋ねるな、命じろ
Column クソコード動画「カプセル化」
13.4 コマンド・クエリ分離
13.5 引数
13.5.1 引数は不変にすること
13.5.2 フラグ引数は使わない
13.5.3 nullを渡さない
13.5.4 出力引数は使わない
13.5.5 引数は可能な限り少なく
13.6 戻り値
13.6.1 「型」を使って戻り値の意図を表明すること
13.6.2 nullを返さない
13.6.3 エラーは戻り値で返さない、例外をスローすること
Column メソッドの名前設計
Column staticメソッドの扱いに注意
第14章 モデリング―クラス設計の土台―
14.1 邪悪な構造に陥りがちなUserクラス
14.2 モデリングの考え方とあるべき構造
14.2.1 システムとは何か
14.2.2 システム構造とモデリング
14.2.3 ソフトウェア設計におけるモデリング
14.3 良くないモデルの問題点と解決方法
14.3.1 Userとシステムの関係
14.3.2 仮想世界を表現する情報システム
14.3.3 目的別にモデリングする
14.3.4 モデルはモノではなく目的達成手段
14.3.5 単一責任とは単一目的
14.3.6 モデルの見直し方
14.3.7 モデルと実装は必ず相互にフィードバックする
Column クソコード動画「Userクラス」
14.4 機能性を左右するモデリング
14.4.1 裏に隠れた真の目的を見破る
14.4.2 機能性をイノベートする「深いモデル」
第15章 リファクタリング―既存コードを成長に導く技―
15.1 リファクタリングの流れ
15.1.1 ネストを解消し、コードの見通しを良くする
15.1.2 意味のある単位にロジックをまとめる
15.1.3 条件を読みやすくする
15.1.4 ベタ書きロジックを目的を表すメソッドに置き換える
15.2 安全にリファクタリングする方法
15.2.1 コードの課題を整理する
15.2.2 テストコードを用いたリファクタリングの流れ
15.3 あやふやな仕様を理解するための分析方法
15.3.1 仕様分析方法1：仕様化テスト
15.3.2 仕様分析方法2：試行リファクタリング
15.4 IDE のリファクタリング機能
15.4.1 リネーム（名前の変更）
15.4.2 メソッド抽出
15.5 リファクタリングで注意すべきこと
15.5.1 機能追加とリファクタリングを同時にやらない
15.5.2 スモールステップで実施する
15.5.3 無駄な仕様は削除することも視野に
Column Railsアプリケーションのリファクタリング
第16章 設計の意義と設計への向き合い方
16.1 本書はなんの設計について書いたものなのか
16.2 設計しないと開発生産性が低下する
16.2.1 要因1：バグを埋め込みやすくなる
16.2.2 要因2：可読性が低下する
16.2.3 木こりのジレンマ
16.2.4 一生懸命仕事した感覚だけが残って生産性は悪いまま
16.2.5 国家規模の経済損失
16.3 ソフトウェアとエンジニアの成長性
16.3.1 エンジニアにとっての資産とは何か
16.3.2 レガシーコードに人は引きずられやすい
16.3.3 レガシーコードは高品質設計を妨げる
16.3.4 レガシーコードは本来やるべき開発の工数を減少させる
16.4 課題を解決する
16.4.1 課題が見えないとそもそも設計する意識が生まれない
16.4.2 知覚容易な課題と知覚困難な課題がある
16.4.3 理想形を知ってはじめて課題を知覚できる
16.4.4 変更容易性を比較できないジレンマ
16.5 コードの良し悪しを判断する指標
16.5.1 実行可能コードの行数
Column クラスを分割すると読みにくくなる？
16.5.2 循環的複雑度
16.5.3 チャンク
16.6 コード分析をサポートする各種ツール
16.6.1 Code Climate Quality
16.6.2 Understand
16.6.3 Visual Studio
Column シンタックスハイライトを品質可視化に利用する
16.7 設計対象と費用対効果
16.7.1 パレートの法則（80:20の法則）
16.7.2 サービスの中心的領域、コアドメイン
16.7.3 重点設計対象の選定には業務知識が必要
16.8 時間を操る超能力者になろう
第17章 設計を妨げる開発の進め方との戦い
17.1 コミュニケーション
17.1.1 コミュニケーションが希薄だと設計品質に問題が生じる
17.1.2 コンウェイの法則
17.1.3 心理的安全性
17.2 設計
17.2.1 「早く終わらせたい」心理が品質低下の罠
17.2.2 粗悪なコードはきれいなコードを書くより常に遅い
17.2.3 設計と実装のフィードバックサイクルを回す
17.2.4 厳密に設計しすぎず、サイクルを回し続けるのがコツ
17.2.5 「パフォーマンスが落ちるからクラスを追加しない」は正しい？
17.2.6 設計ルールを多数決で決めるとコード品質は最低になる
17.2.7 設計ルールづくりのポイント
17.3 実装
17.3.1 割れ窓理論とボーイスカウトの規則
17.3.2 既存コードを信用せず、冷静に正体を見破る
17.3.3 コーディング規約を利用しよう
17.3.4 命名規約
17.4 レビュー
17.4.1 コードレビューをしくみ化しよう
17.4.2 コードを設計視点でレビューしよう
17.4.3 敬意と礼儀
17.4.4 定期的に改善タスクを棚卸しすること
17.5 チームの設計力を高める
17.5.1 影響力を持つレベルにまで仲間を集める
17.5.2 基本はスモールステップ
17.5.3 実感が大事、手を動かしてみよう
17.5.4 フォローアップ勉強会を開いてみよう
17.5.5 勉強会のバッドノウハウ
17.5.6 リーダーやマネージャーに設計と費用対効果の話をする
17.5.7 設計責任者を立てる
第18章 設計技術の理解の深め方
18.1 さらにステップアップするための設計技術書紹介
18.1.1 現場で役立つシステム設計の原則―変更を楽で安全にするオブジェクト指向の実践技法
18.1.2 リーダブルコード―より良いコードを書くためのシンプルで実践的なテクニック
18.1.3 リファクタリング 既存のコードを安全に改善する（第2版）
18.1.4 Clean Code アジャイルソフトウェア達人の技
18.1.5 レガシーコード改善ガイド
18.1.6 レガシーソフトウェア改善ガイド
18.1.7 レガシーコードからの脱却―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
18.1.8 エンジニアリング組織論への招待―不確実性に向き合う思考と組織のリファクタリング
18.1.9 プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則
18.1.10 Clean Architecture 達人に学ぶソフトウェアの構造と設計
18.1.11 エリック・エヴァンスのドメイン駆動設計
18.1.12 ドメイン駆動設計をはじめよう―ソフトウェアの実装と事業戦略を結びつける実践技法
18.1.13 セキュア・バイ・デザイン 安全なソフトウェア設計
18.1.14 ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本
18.1.15 ドメイン駆動設計 モデリング/実装ガイド
18.1.16 ドメイン駆動設計 サンプルコード＆ FAQ
18.1.17 テスト駆動開発
Column バグ退治RPG『バグハンター2 REBOOT』
18.2 設計スキルを高める学び方
18.2.1 インプットは2／アウトプットは8
18.2.2 設計効果を意識する
18.2.3 悪魔の構造を見破る練習
18.2.4 リファクタリングで大幅スキルアップ
18.2.5 設計の良し悪しを説明できることがスキルアップにつながる
Column C#と長き旅、そして設計への道
18.2.6 動くコードを書いたら、設計し直してからコミット
18.2.7 設計技術書でさらなる高みを目指そう
参考文献
索引
