なぜコンポジションはインヘリタンスより好まれることが多いのか？

Question

Accepted Answer

**コンポジション・オーバー・インヘリタンス**は広く引用されている設計原則です — ベースクラスから継承する（インヘリタンス）のではなく、動作を**組み合わせる**（コンポジション）ことでオブジェクトを構築することを支持しています。インヘリタンスは重大な欠点を持っていますが、コンポジションはそれらを回避します。ただし、両者にはそれぞれの位置があります。

## インヘリタンス対コンポジション

```text
INHERITANCE → a class EXTENDS another, inheriting its behavior ("IS-A" relationship):
  class Dog extends Animal
COMPOSITION → a class is BUILT FROM other objects/behaviors ("HAS-A" / uses):
  class Car { constructor() { this.engine = new Engine(); } }   // composes behaviors
→ composition: combine smaller pieces; inheritance: derive from a parent
```

## インヘリタンスの問題点

```text
✗ TIGHT COUPLING → subclasses are tightly bound to their parent's implementation (changes
  to the parent can break subclasses — the "fragile base class" problem)
✗ RIGID hierarchies → deep/wide inheritance trees become hard to change and understand
✗ Inflexible → a class can usually only inherit from ONE parent; behavior is fixed at compile
  time; hard to combine behaviors from multiple sources
✗ Forces an "IS-A" relationship that may not truly hold; exposes parent internals
```

## コンポジションが優れている理由

```text
✓ FLEXIBLE → compose behaviors as needed; combine multiple behaviors; change at RUNTIME
✓ LOOSE COUPLING → objects depend on interfaces of composed parts, not parent implementations
✓ REUSABLE → small, focused components reused in many combinations
✓ Easier to change/test; avoids fragile hierarchies; favors small, focused pieces
→ many patterns (Strategy, Decorator) use composition; "favor composition over inheritance"
  ⚠️ inheritance still has valid uses (true IS-A, sharing interface) → use it appropriately
```

## なぜ重要なのか

コンポジションがインヘリタンスより好まれることが多い理由を理解することは、価値あるシニアレベルの知識です。これは**基本的な設計原則**であり、柔軟性と保守性を改善し、成熟した設計判断を反映しているためです。

「コンポジションをインヘリタンスより優先する」という原則は広く引用されています。なぜなら、インヘリタンスはオブジェクト指向の基本機能ですが、重大な欠点を持っているからです。

**区別を理解する**ことが基本です — インヘリタンスは親を拡張する「IS-A」関係であり、コンポジションは他のオブジェクトから構築する「HAS-A」関係です。

**インヘリタンスの問題を理解する**ことが重要な洞察です：**密結合**（サブクラスが親の実装に束縛され、親の変更がサブクラスを破損させる — 脆い基底クラス問題）、**硬い階層構造**（深いインヘリタンスツリーが変更と理解を困難にする）、**柔軟性の欠如**（通常は単一インヘリタンスのみ、動作がコンパイル時に固定される、複数ソースからの動作を組み合わせるのが難しい）、および成立しないIS-A関係を強制すること。

これらは実質的で重大な問題であり、保守の困難さを引き起こします。

**コンポジションが優れている理由を理解する** — **柔軟性**（必要に応じて動作を合成・組み合わせ、実行時に変更可能）、**疎結合**（親の実装ではなく合成される部品のインターフェースに依存）、**再利用性**（小規模で集約されたコンポーネントが多くの組み合わせで再利用される）、そして変更とテストが容易 — これらはコンポジションがインヘリタンスの欠点を回避する理由を説明しています。

多くのパターン（Strategy、Decorator）がコンポジションを使用する一方、インヘリタンスには依然として有効な用途がある（真のIS-A関係、インターフェースの共有）ことを認識することは、バランスの取れた判断を反映しています — コンポジションは*しばしば*優先されますが、インヘリタンスにはその位置があります。

この原則は柔軟で保守性の高い設計の基本です。

「コンポジションをインヘリタンスより優先する」は基本的で広く引用される設計原則であり、インヘリタンスの実際の欠点（結合、硬さ、柔軟性の欠如）とコンポジションの利点（柔軟性、疎結合、再利用性）を理解する — インヘリタンスの有効な用途を認識しながら — は、成熟した設計判断を反映しています。これはコードの品質を改善し、コンポジションがインヘリタンスより好まれる理由を理解することは価値あるシニアレベルの知識 — 柔軟で保守性の高いコードのための基本的な設計原則であり、多くのパターンを支えており、成熟した設計判断（コンポジションを優先しながらインヘリタンスの位置を知る）を反映しています。これはシニア開発者が設計の良いオブジェクト指向ソフトウェアを書く際に期待されるものです。