概要
オブジェクト指向（OOP）は、いまやあまりにも多くの現場で「習慣」として採用されている。
しかしその本質的な意義や設計思想は、往々にして誤解や形式主義の中で形骸化している。
- なぜ「オブジェクト」が必要なのか？
- 「振る舞いを持つデータ」という概念に、どんな設計的意味があるのか？
- そして関数型（FP）とどう本質的に異なるのか？
本稿では、「オブジェクト指向とは何か？」を再定義し、現代的ソフトウェア開発における実践的な設計基準として読み解く。
1. 古典的な定義：データと振る舞いの結合
オブジェクトとは、状態（データ）と振る舞い（メソッド）を持つ自己完結型の構造体である。
class User {
constructor(private name: string) {}
greet(): string {
return `Hello, ${this.name}`
}
}
- 状態：
name - 振る舞い：
greet - この結合こそが、OOPのコア設計単位
2. データ主義 vs 振る舞い主義
OOPがFPと最も異なるのは、**「データに対して関数を当てる」のではなく、「データそのものが関数を持つ」**点にある。
| パラダイム | データ構造 | 振る舞いの位置付け |
|---|---|---|
| 関数型 | 受動的な構造体 | 関数が外から作用する |
| OOP | 能動的な構造体 | 振る舞いが中にある |
// 関数型的アプローチ
type User = { name: string }
const greet = (user: User) => `Hello, ${user.name}`
// OOP的アプローチ
class User {
constructor(public name: string) {}
greet() { return `Hello, ${this.name}` }
}
→ OOPは、データに主権を持たせることで、責務と制御をカプセル化する。
3. オブジェクトが設計に果たす役割
✅ カプセル化（Encapsulation）
- 状態と振る舞いを構造的に一体化することで、不変性と整合性を担保
- 外部からのアクセスは、限定されたAPIを通じてのみ許容
✅ 責務の単位化
- オブジェクトは**「概念の境界線」**
- その責務が曖昧になると、設計が崩壊する
class Order {
constructor(private items: Item[]) {}
totalAmount(): number {
return this.items.reduce((sum, item) => sum + item.price, 0)
}
}
→ ロジックをオブジェクト側に保持することで、ビジネスルールを「意味のある構造」に内包できる
4. OOPの誤解と逸脱
❌ DTO（データだけのオブジェクト）を量産
class UserDto {
constructor(public name: string, public age: number) {}
}
→ 振る舞いを持たないなら、それはただの構造体
→ DTOをOOPと呼ぶのは、設計思想の放棄
❌ ロジックがサービスクラスに集約されすぎる
class OrderService {
calculateAmount(order: Order): number { /* ... */ }
}
→ オブジェクトが「ただの箱」になり、ドメイン知識が外部に漏れ出す
→ 正しいアプローチは「ロジックをドメインモデルの中に閉じる」
5. 設計判断フロー：それは「データ」か「概念」か？
① 状態と振る舞いが密接に関係している？ → YES → クラスとして表現
② ロジックが他のコンポーネントに依存していない？ → YES → オブジェクトに閉じ込める
③ その構造体は振る舞いを必要としない？ → YES → 単なるデータ型（Record）で十分
④ ロジックが手続き型でバラバラに散らばっている？ → YES → 責務単位で構造を再編成
6. モデリング視点のOOP設計
良いOOPとは、単なる構文スタイルではない。
それは**「概念を閉じ込める構造体を、意味のある単位として設計する行為」**である。
- ユーザーとは何か？
- 注文とは何を保持し、どう振る舞うべきか？
- それは誰に対して責任を負うべきか？
→ これを設計単位で「オブジェクト」として表現することが、**ドメイン駆動設計（DDD）**とも一致してくる。
結語
オブジェクト指向の本質とは、**「振る舞いを持った意味のある構造体によって、コードを秩序化する技法」**である。
- 状態と責務を同居させ
- 意味のあるインターフェースを定義し
- 振る舞いをドメインに沿って封じ込める
それにより、ロジックは整理され、拡張に強く、テストしやすい構造になる。
オブジェクト指向とは、
“概念を閉じ、責務を分離し、振る舞いを構造として設計に昇華する哲学である。”