POODR 第1章：オブジェクト指向設計

概要

第1章は本全体の枠組みを提示する。Sandi Metz は、設計とは厳格なルールに従うことでも、パターンをそれ自体のために適用することでもないと主張する。設計とは、コードを今日も明日も安価に変更できるように配置することだ。この章は、以降のすべての内容に向けた語彙と考え方を用意する。

なぜ設計が重要なのか

ソフトウェアには2つの仕事がある。今動くことと、後で簡単に変更できることだ。動かすことは分かりやすい部分である。隠れていてコストがかかる部分は変更だ — 要件は変わり、機能は追加され、バグは修正される。ソフトウェアのコストの大半は、最初のバージョンを出荷した後に発生する。

問題は、書きやすいアプリケーションはしばしば変更しにくく、その逆もまた然りだということだ。よく設計されたアプリケーションは変更を優雅に吸収する。設計の悪いアプリケーションは、触るたびに次第にコストがかさみ、やがて変更のコストが全体を「もう割に合わない」と感じさせるほどになる。

設計とはコードを配置する技術である。

変更のコスト

Metz は設計を 経済的な問題 として捉え直す。ソフトウェアの 正味現在コスト — 構築コストと将来のすべての変更コストの合計 — をできる限り低く抑えたい。次の2つの失敗モードはどちらもコストを生む。

設計不足（設計がまったくない）：コードは依存関係の沼と化し、どんな変更も予期せぬ何かを壊す。
過剰設計：将来を見越して手の込んだ抽象を用意するが、それが報われることは決してなく、その投機的な複雑さが邪魔になる。

目指すのは ちょうど十分な 設計であり、想像上の必要ではなく現実の必要が生じたときに適用するものだ。

オブジェクト指向設計が本当に扱っているもの

オブジェクト指向のアプリケーションは、互いに メッセージ を送り合う オブジェクト で構成される。意外な洞察はこうだ。メッセージは実はオブジェクトよりも重要である。重要なのは、各オブジェクトが何を知り何をするかだけでなく、オブジェクトどうしがどのように対話するかだ。

やっかいなのは 依存関係 だ。あるオブジェクトが別のオブジェクトについて知りすぎると、両者は絡み合ってしまう。一方を変えれば、もう一方も変えざるを得なくなる。依存関係が多すぎる単一のオブジェクトは脆く、過剰に結合したオブジェクトの網はあらゆる変更に抵抗する。

オブジェクト指向設計とは、根本的には依存関係を管理することである。

設計とは、オブジェクトが変更に耐えられるようにコードを配置するための一連の技術である。依存関係が制御されていれば、オブジェクトは独立して進化できる。

道具立て：原則とパターン

Metz は、よい設計の指針となる2つの知識体系を挙げる。

原則 — 最も有名なのが SOLID だ：
- Single Responsibility（単一責任）
- Open/Closed（開放/閉鎖）
- Liskov Substitution（リスコフの置換）
- Interface Segregation（インターフェイス分離）
- Dependency Inversion（依存性逆転）
さらに DRY（Don't Repeat Yourself）や Law of Demeter といった補助的な考え方もある。これらは経験と研究に裏打ちされ、蒸留され名付けられた指針である。
パターン — Gang of Four のデザインパターン：よくある問題に対する、名前の付いた再利用可能な解決策だ。パターンには価値があるが、それが設計された問題に適用したときに限られる。誤って適用されたパターンは、問題の一部になってしまう。

本書の残りは、これらの考え方を実際の Ruby コードの中で実用的に適用することを扱う。

Ruby のオブジェクトモデルについての短いメモ

この章は、Ruby における「クラス」の意味についての短いおさらいで締めくくられる。クラスはオブジェクトの設計図であり、オブジェクトはメッセージに応答し、あらゆるもの（数値、文字列、nil）がオブジェクトである。Ruby の柔軟性は、美しいコードを書く大きな力を与えてくれる — と同時に、こんがらがった混沌を書く同じくらい大きな力も与える。設計こそが、その境界線の正しい側にあなたを留めてくれるものだ。

重要なポイント

設計の目的は変更のコストを減らすことである — それを儀式ではなく経済的な意思決定として扱うこと。
アプリケーションはメッセージをやり取りするオブジェクトである。そのメッセージの配置こそが本当の設計だ。
依存関係は敵である — オブジェクト指向設計は、それを管理する規律である。
設計不足も過剰設計もコストを生む — 現実の必要に導かれた「ちょうど十分な」設計を目指すこと。
原則（SOLID、DRY、Law of Demeter）とパターン は道具であり、思慮深く適用したときにのみ価値を持つ。
Ruby は自由を与えてくれる。設計とは、その自由が混沌になるのを防ぐ方法である。

🌐 Claudeによる翻訳