データと振る舞いを「オブジェクト」として一体化し、カプセル化・継承・ポリモーフィズムを核に設計するプログラミングパラダイム。Alan Kay が Smalltalk で体系化した。
概要
手続き型が「処理の手順」を中心に書くのに対し、オブジェクト指向は 「誰が何の責務を持つか」 を中心に書く。データ構造とそれを操作するロジックを 1 つのクラスに閉じ込め、外からは公開された振る舞いだけを通じて利用させる。
3 つの基本概念
| 概念 | 説明 | 例 |
|---|---|---|
| カプセル化 | データと操作を 1 つにまとめ、内部状態を隠蔽する | Account クラスが残高を private に持ち、withdraw() 経由でしか変更できない |
| 継承 | 既存クラスの責務を引き継ぎつつ拡張する | SavingsAccount extends Account |
| ポリモーフィズム | 同じインターフェースで異なる実装を切り替える | PaymentMethod を実装した CreditCard / BankTransfer |
なぜ階層分離が必要なのか
オブジェクト指向の真価は「クラスの数」ではなく 責務の分離にある。ドメインロジック・アプリケーション制御・インフラアクセス・UI を別レイヤーに配置することで、変更理由ごとにコードが孤立し、AI 生成コードの修正範囲も予測可能になる。
| レイヤー | 責務 | 変更頻度 |
|---|---|---|
| ドメイン層 | ビジネスルール | 低（仕様変更時のみ） |
| アプリケーション層 | ユースケース調整 | 中 |
| インフラストラクチャー層 | DB・外部 API | 高（基盤交換時） |
| インターフェース層 | UI・REST 入口 | 高 |
レガシーシステムとの関係
COBOL や RPG は手続き型だが、サービスプログラム（*SRVPGM）やコピーブックで「責務の単位」を切り出す運用は、オブジェクト指向の発想を先取りしている。モダナイゼーション時にはこの単位がそのままクラス・サービスの境界候補になる。
マルチモール EC での適用イメージ
CTS-EC 共通商品マスタの Source → Master → Mall という 3 層構成は、責務分離をドメイン境界として表現した例。Source 層は外部システムからの取り込み、Master 層は共通マスタへの正規化、Mall 層はモール固有フォーマットへの変換、と層ごとに変更理由が独立している。各層の境界が明確だと、AI に「Mall 層に Amazon 用変換を追加して」と指示しても影響範囲が層内に収まり、レビューと回帰確認のコストが下がる。
関連記事
- 開発手法ガイド：概要 — オブジェクト指向を起点とした設計原則の積み上げ
- COBOL × DDD 設計パターン — 手続き型言語にオブジェクト指向の責務分離を適用する例
- CTS-EC 共通商品マスタ — 責務分離を 3 層アーキテクチャで体現した実例
関連用語
- SOLID 原則 — オブジェクト指向設計の 5 つの基本原則
- DDD — オブジェクト指向を業務ドメインに適用した設計手法
- RDD（責務駆動設計） — 責務を起点にクラス分割を進める手法
- リポジトリパターン — ドメインを永続化詳細から切り離す責務分離パターン
- ヘキサゴナルアーキテクチャ — 階層分離をアーキテクチャ全体に適用した形
- SoC（関心の分離） — オブジェクト指向の階層分離を支える上位原則