オブジェクト指向とは？なぜデザインパターンが必要？
デザインパターンの学習を始めると、
「そもそもなぜデザインパターンが生まれたのか？」
「オブジェクト指向とどう関係しているのか？」
が曖昧なまま、各パターンの実装だけを追ってしまいがちです。
この記事では、TechScore のデザインパターン解説を参考にしながら、
- オブジェクト指向とは何か
- なぜデザインパターンが必要になったのか
- デザインパターンとは何を解決するものなのか
を 導入編 として整理します。
オブジェクト指向とは？
オブジェクト指向（Object-Oriented Programming, OOP） とは、 「データ（状態）」と「振る舞い（操作）」をひとまとまりの オブジェクト として扱う考え方です。
例えば「ユーザー」という概念を考えると、
- 名前や年齢などの データ
- ログインする、プロフィールを更新するなどの 振る舞い
を 1 つの単位として設計します。
User という 1つのオブジェクト が
・状態（name, email）
・振る舞い（login, updateProfile）
をまとめて持つ
オブジェクト指向の代表的な特徴
- カプセル化：内部の詳細を隠し、必要な操作だけを公開する
- 継承：共通の性質を持つクラスを再利用する
- ポリモーフィズム：同じ操作でも、振る舞いを差し替えられる
これにより、現実世界の概念に近い形でシステムを設計でき、
コードの再利用性や拡張性を高めることができます。
オブジェクト指向だけでは足りなかった理由
「オブジェクト指向を使えば、すべてがうまくいく」
現実はそう単純ではありません。
システムが大きくなるにつれて、次のような問題が発生します。
- クラス同士の依存関係が複雑になる
- 変更の影響範囲が読めなくなる
- 同じような設計上の悩みを、毎回違う方法で解決してしまう
結果として、
「動くけど、変更しづらいコード」
「意図が読み取れない設計」
が量産されてしまいます。
ここで重要なのは、 問題は実装ではなく「設計」にあった という点です。
デザインパターンとは何か？
デザインパターン とは、
オブジェクト指向設計において頻出する問題に対する、再利用可能な解決の型 です。
ポイントは次の 2 つです。
- 特定の言語やライブラリに依存しない
- 「コード」ではなく「構造・役割・責務」を定義する
つまりデザインパターンは、
「この状況では、こういうクラス構成・役割分担にすると破綻しにくい」
という 設計ノウハウの集約 です。
参考
- https://refactoring.guru/design-patterns/what-is-pattern
- https://www.techscore.com/tech/DesignPattern/foundation/
なぜデザインパターンが必要なのか？
デザインパターンが生まれた背景には、次の理由があります。
1. 同じ問題が何度も現れるから
大規模・長期運用のシステムでは、
「変更に弱い」「拡張しづらい」といった問題が繰り返し発生します。
デザインパターンは、
そうした 過去に何度も現れ、解決されてきた問題の集大成 です。
2. 設計の共通言語になるから
「この処理、Strategy パターンでいこう」
「ここは Observer がハマりそう」
といった会話ができると、
設計意図を短い言葉で正確に共有できます。
3. 変更に強い設計を作りやすくなるから
多くのデザインパターンは、
- 依存を減らす
- 変更点を局所化する
ことを目的にしています。
結果として、 仕様変更が前提の現実的なシステム を作りやすくなります。
以下の図は、「依存を減らしたい」という Before / After の対比図になります。
Before→変更に弱く、改修が難しくなる
After→責務を分離
- OrderService は 「通知する」ことだけを知っていればいい
- 実際に何で通知するかは、別の責務に切り出す
- この「考え方」が デザインパターンの正体
参考
GoF（Gang of Four）と 23 のデザインパターン
デザインパターンが体系的に整理されたのは、
1995 年に出版された以下の書籍がきっかけです。
Design Patterns: Elements of Reusable Object-Oriented Software
著者 4 人（通称 GoF: Gang of Four）によって、23 個のデザインパターンが整理されました。
これらは現在でも、多くの言語・フレームワークの基礎になっています。
参考
デザインパターンの分類
GoF のデザインパターンは、大きく 3 つに分類されます。
1. 生成に関するパターン（Creational）
- オブジェクトの 生成方法 に関する問題を解決
- 例：Singleton, Factory Method
2. 構造に関するパターン（Structural）
- クラスやオブジェクトの 組み合わせ方 を整理
- 例：Adapter, Facade
3. 振る舞いに関するパターン（Behavioral）
- オブジェクト間の 責務分担や連携方法 を整理
- 例：Observer, Strategy
この分類を頭に入れておくと、
「このパターンは何を解決したいのか？」が見えやすくなります。
まとめ
- オブジェクト指向は「現実世界をモデル化する」ための考え方
- しかし、設計が複雑になると破綻しやすい
- デザインパターンは、設計の失敗を減らすための知恵の集合体
- 実装ではなく「構造」と「責務」を学ぶことが重要
次回以降の記事では、
各デザインパターンを 1 つずつ、
「どんな問題を解決するのか」→「なぜその構造になるのか」
という視点で解説していきます。