TL

オブジェクト指向プログラミング(OOP)

データ(状態)と処理(振る舞い)を“オブジェクト”にまとめて、現実の概念のようにプログラムを組み立てる考え方。

中級OOP設計パラダイム最終更新: 2026-06-04
TL;DR要点だけ先に
  • 1.OOP は データと処理を“オブジェクト”にまとめ、現実の概念のように組み立てる考え方。
  • 2.4本柱:カプセル化(隠す)・継承(受け継ぐ)・ポリモーフィズム(同じ呼び方で違う動き)・抽象化(本質だけ見せる)。
  • 3.継承よりコンポジション(部品の組み合わせ)が安全。“is-a”か“has-a”かで選ぶ。

何がうれしい?

手続き型では「データ」と「それを触る関数」がバラバラになりがちで、規模が大きくなると「このデータ、どこから書き換えられてる?」が追えなくなります。OOP は、

  • 関係するデータと処理を1か所にまとめる(凝集)
  • 外から触ってよい範囲を絞る(カプセル化)
  • 似たものを共通化・差し替えしやすくする

クラスとインスタンス

  • クラス: オブジェクトの「設計図」(例: Dog
  • インスタンス: 設計図から作った「実体」(例: pochi = new Dog("ポチ")
class Dog {
  constructor(name) {
    this.name = name;       // 状態(プロパティ)
  }
  bark() {                  // 振る舞い(メソッド)
    return `${this.name}: ワン!`;
  }
}
const pochi = new Dog('ポチ');
pochi.bark(); // "ポチ: ワン!"

4本柱

ひとことで
カプセル化内部を隠し、決まった窓口だけ公開する残高は private、入出金メソッド経由でのみ変更
継承共通部分を親から受け継ぐDog/Cat が Animal を継承
ポリモーフィズム同じ呼び方で、型ごとに違う動きanimal.speak() が犬は鳴き、猫は鳴く
抽象化本質だけ見せ、複雑さを隠す車は「アクセル」だけ、内部の燃焼は隠す

手続き型との違い

観点手続き型オブジェクト指向
中心関数(処理の手順)オブジェクト(データ+処理)
データ関数間で共有・受け渡しオブジェクト内に閉じ込める
拡張関数を足すクラスを足す/継承する
向く規模小〜中・直線的な処理中〜大・状態が多いドメイン

つまずきポイント

継承の濫用に注意

「コードを共有したいから継承」は危険。親の変更が全子クラスに波及し、密結合になります。“is-a”(猫は動物だ)なら継承、“has-a”(車はエンジンを持つ)ならコンポジション(部品として持つ)が原則。"継承より合成" は OOP の定番格言です。

ポリモーフィズムが効くと if が減る

型ごとの分岐(if (type === 'dog') ... else if (type === 'cat') ...)は、共通インターフェースの speak() に置き換えると消えます。条件分岐の塊を見たら、ポリモーフィズムの出番かも。

どんな時に使う?

  • 状態を持つ「もの」が多いドメイン(ゲーム、業務システム、UIコンポーネント)
  • 似たバリエーションを差し替えたい(プラグイン、戦略の切り替え)
  • 逆に、純粋な変換処理が中心なら関数型の考え方が向くことも。OOP は道具の1つで、万能ではありません。

プログラミング Article

オブジェクト指向プログラミング(OOP)を実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

OOP

比較で見る軸

難易度: intermediate / カテゴリ: プログラミング / タグ数: 3

導入後に効く点

4本柱:カプセル化(隠す)・継承(受け継ぐ)・ポリモーフィズム(同じ呼び方で違う動き)・抽象化(本質だけ見せる)。

先に潰すリスク

用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。

数字・仕様の読み方
難易度
intermediate
カテゴリ
プログラミング
タグ数
3

判断チェックリスト

  • 自社の用途が「OOP / 設計」に近いか確認する。
  • 強みである「OOP は データと処理を“オブジェクト”にまとめ、現実の概念のように組み立てる考え方。」が本当に評価軸になるか確認する。
  • 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

OOP設計パラダイムOOP設計パラダイム
参考: 公式情報