目次

• 改訂新版　まえがき
• はじめに
• 謝辞

第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　設計技術書でさらなる高みを目指そう

• 参考文献
• 索引