オブジェクト指向とは？カプセル化・継承・ポリモーフィズムを実装目線で解説

オブジェクト指向とは、データ（状態）と処理（振る舞い）を「オブジェクト」という単位にまとめ、プログラムを部品の組み合わせとして設計する考え方です。中心になるのがカプセル化・継承・ポリモーフィズムの三本柱で、それぞれ担う役割がはっきり分かれています。この記事では、三つを定義だけで終わらせず、Javaのアクセス修飾子やメソッド再定義といった実装レベルまで落として整理します。さらに手続き型・関数型・データ指向との使い分け、実務でつまずきやすい継承の乱用、受託開発や保守運用で設計が効く条件まで、実装者が判断に使える形でまとめました。

まとめ：三本柱の役割分担と、継承より合成を優先する判断軸

三本柱は目的が異なります。カプセル化は内部状態を隠してデータの整合性を守り、継承は共通コードを親にまとめて重複を減らし、ポリモーフィズムは呼び出し側のコードを変えずに振る舞いだけを差し替えます。設計で最初に効くのがカプセル化です。公開する窓口（メソッド）を絞るほど、後からの変更に強くなります。

実務での判断軸はひとつ、「継承を第一候補にしない」ことです。親子の型が本当に is-a（〜は〜の一種）で結べるときだけ継承を使い、コードの再利用が目的なら合成（フィールドとして別オブジェクトを持つ）を選びます。継承を安易に重ねた設計は、親の変更が子を壊す連鎖を生み、保守フェーズで最も高くつく典型例です。以下では各要素の実装と、この判断基準の根拠を順に説明します。

オブジェクト指向が解決したい手続き型プログラミングの限界と背景

オブジェクト指向は1960年代のSimula、1980年代のSmalltalkを起点に広がり、C++・Java・C#・Python・Rubyなど主要言語の設計思想へ組み込まれました。生まれた動機は明確で、手続き型プログラミングが抱える「データと処理が分離したまま規模が膨らむ」問題を解くことにあります。

オブジェクト指向が解決したかった手続き型の構造的な弱点と背景

手続き型では、データはグローバルな変数や構造体として置かれ、処理はそれを外から書き換える関数の集合になります。規模が小さいうちは読みやすい一方、データを触れる場所がコード全体に散らばるため、値が想定外に壊れたとき原因の特定に時間がかかる点が弱点です。仕様変更で1つのデータ構造に項目を足すと、それを参照する関数を横断的に直す必要が出ます。オブジェクト指向は、データとそれを操作する処理を同じオブジェクトへ閉じ込め、影響範囲をオブジェクト内部に限定することでこの弱点に対処します。

クラスとインスタンスの関係と、状態と振る舞いを束ねる基本単位

クラスは設計図、インスタンスはその設計図から作った実体です。クラスはフィールド（状態を持つ変数）とメソッド（振る舞いを表す関数）を1つの単位として定義し、new で生成したインスタンスがそれぞれ独立した状態を持ちます。たとえば注文を表す Order クラスは、金額や明細というフィールドと、合計を計算する calcTotal というメソッドを一緒に持ちます。データと計算ロジックが同居するため、「金額の計算規則」を変えたいときに触る場所は1クラスに収まる形です。この凝集こそが、規模が大きい業務システムで効いてきます。

カプセル化とは：内部状態の隠蔽とアクセス制御を実装する手順と効果

カプセル化は三本柱の土台です。オブジェクトの内部フィールドを外から直接触らせず、公開するメソッド経由でしか読み書きできないようにして、データが不正な状態になる経路を塞ぎます。

アクセス修飾子で公開範囲を絞り込むカプセル化の具体的な実装手順

Javaではフィールドを private で宣言し、外部からの参照や更新を public なメソッド（ゲッター・セッター）に限定します。protected は継承先だけに公開する中間の範囲です。この3段階で「誰が触れてよいか」を型の宣言として固定できます。ポイントは、セッターに検証ロジックを置ける点です。たとえば残高フィールドを private にし、更新用メソッドの中で「マイナスにならない」条件を検査すれば、残高が負になる状態はコード上で作れなくなります。フィールドを公開したままでは、この不変条件を全呼び出し箇所で守らせる保証がありません。

情報隠蔽が内部実装の変更コストを下げる仕組みと実装判断の目安

カプセル化の実利は、公開する窓口を狭くするほど内部実装を自由に差し替えられることにあります。外部が触るのがメソッドの入出力だけなら、内部のデータ構造をリストからマップへ変えても、呼び出し側は影響を受けません。逆に、フィールドをそのまま外部へ公開した設計は、内部構造の変更がそのまま外部の修正に波及します。実装判断の目安は単純で、「そのフィールドを外から書き換える正当な理由があるか」を問い、無ければ private にして読み取り専用にするのが定石です。カプセル化の詳細な実装例やアクセス修飾子の使い分けは、カプセル化とは何か？オブジェクト指向における基本概念を解説でコードとともに掘り下げています。

継承とは：is-a関係によるコードの共通化と、その乱用が招く落とし穴

継承は、既存クラスの状態と振る舞いを引き継いで新しいクラスを作る仕組みです。共通部分を親にまとめれば重複コードは減りますが、使いどころを誤ると保守を難しくする副作用が最も出やすい要素でもあります。

継承の実装方法と、is-a関係が成立するかどうかの見極め基準

Javaでは extends で親クラスを指定し、子クラスは親のフィールドとメソッドを引き継ぎます。継承を使ってよいのは、子が親の一種だと言い切れる is-a 関係のときだけです。「正社員は従業員の一種」なら Employee を親に置けます。一方、「注文は顧客が持つもの」という has-a の関係を継承で表すのは誤りで、これは合成（フィールドとして持つ）で表現します。判断のコツは、「子は親として扱っても破綻しないか」を確認することです。親を受け取る処理に子を渡して意味が通るなら継承が成立します。

継承の乱用がコードの密結合を招く、典型的な失敗パターンと兆候

継承の落とし穴は、親の実装変更が子へ予期せず波及する密結合です。コードを再利用したいだけの理由で無関係なクラスを継承すると、親のメソッドを1つ直しただけで、それを暗黙に前提にしていた複数の子が同時に壊れます。継承の階層が3段4段と深くなるほど、あるメソッドが最終的にどう振る舞うかを追うコストが上がります。実装では「共通化のために継承したくなったら、まず合成で置き換えられないか」を先に検討する習慣が有効です。継承と合成の切り分けは後半の独自章で判断基準を示します。

ポリモーフィズムとは：呼び出し側を変えずに振る舞いを差し替える仕組み

ポリモーフィズムは、同じ呼び出し方で異なる振る舞いを実行できる仕組みです。呼び出し側のコードを変えずに、渡すオブジェクトの型によって処理を切り替えられるため、拡張に強い設計の要になります。

メソッドの再定義とインタフェースによる振る舞いの切り替えの実装

実現手段は主に2つです。1つはメソッドのオーバーライドで、親のメソッドを子で @Override を付けて再定義します。もう1つはインタフェースで、interface に共通の窓口だけを宣言し、複数のクラスが implements でそれぞれの実装を持つ形です。たとえば「通知を送る」という Notifier インタフェースを定義し、メール送信クラスとチャット送信クラスが同じメソッド名で別々の処理を実装すれば、呼び出し側は Notifier 型として受け取るだけで済みます。送信手段が増えても、呼び出し側のコードには手を入れません。

型ごとの長い条件分岐をポリモーフィズムへ置き換える判断の基準

ポリモーフィズムが効くのは、型ごとに処理を分ける長い条件分岐が出てきた場面です。種別を見て振る舞いを切り替える switch や if の連鎖は、種別が増えるたびに全箇所へ分岐を足す必要が生じます。これをインタフェースと実装クラスへ置き換えると、新しい種別はクラスを1つ追加するだけで済み、既存コードを触りません。ただし種別が2つで今後も増えないと分かっているなら、無理に抽象化せず条件分岐のままにする判断も妥当です。カプセル化・継承・ポリモーフィズムの三者の違いと役割は、カプセル化とポリモーフィズム：継承との違いと役割でさらに具体的に整理しています。

手続き型・関数型・データ指向とオブジェクト指向の使い分けの判断軸

オブジェクト指向はあらゆる場面で最善の設計とは限りません。手続き型・関数型・データ指向にはそれぞれ得意な領域があり、扱うデータの性質と変更の入り方で選び分けます。

各パラダイムの得意領域を一覧で比べる設計アプローチ選択の指針

下表は、状態の扱い・変更に強い箇所・向く規模という観点で4つの考え方を比べたものです。オブジェクト指向が効くのは、状態を持つ実体が多く、型の追加という形で機能が増えていく中〜大規模の業務システムです。大量データを一括で流し込んで変換する処理が中心なら、データ側の構造を主役に据えるデータ指向のほうが素直に書けます。

データ中心にシステムを設計する考え方は、オブジェクト指向と対になる発想です。分散データや大量処理を前提にした設計の基本原則は、データ指向アプリケーションデザインの基本原則と利点で扱っています。どちらか一方だけが正解ではなく、扱う対象で選び分けるのが実務の姿勢です。

継承より合成を第一候補にする実装判断の基準と、見送るべき場面

ここは競合記事が手薄な独自の論点です。結論を先に言い切ると、コードの再利用が目的なら継承ではなく合成（コンポジション）を第一候補にします。継承を選ぶのは、子が親の一種だと型として言い切れる is-a 関係が成立する場合に限定します。

合成を第一候補にする理由と、継承を採用してよい2つの前提条件

合成は、別クラスのインスタンスをフィールドとして持ち、必要な機能をそのオブジェクトへ委譲する書き方です。継承と違い親子の型が縛られないため、持つ相手を後から差し替えられ、テスト時にはモックへ置き換えるのも容易になります。継承を採用してよい条件は2つです。第一に、親を受け取る処理へ子を渡しても意味が破綻しない（型の置換が成り立つ）こと。第二に、親の変更を子へ確実に波及させたい設計意図があること。この2つを満たさない再利用目的の継承は、合成へ置き換えます。

継承を見送るべき具体的な失敗場面と、合成へ切り替える判断基準

継承を見送るべき場面を条件付きで挙げます。まず、共通のメソッドを使いたいだけで型の親子関係に必然性がないとき。この場合の継承は、親の些細な修正で無関係な子が壊れる密結合を生むため採用しません。次に、階層がすでに2段あり、そこへさらに継承を重ねようとしているとき。深い継承は振る舞いの追跡コストが跳ね上がるので、合成か、共通処理を別クラスへ切り出す設計に切り替えます。逆に、フレームワークが基底クラスの継承を前提にしている場合は、その作法に従って継承を使うのが自然です。「継承は禁止」ではなく、「再利用目的では選ばない」という線引きが実務では機能します。

受託開発と保守運用でオブジェクト指向の設計が投資に見合う条件

オブジェクト指向は、作って終わりではなく長く保守するシステムでこそ投資が回収されます。設計に手をかける価値があるかは、システムの寿命と変更頻度で見極めます。

保守フェーズで設計品質がシステムの総保有コストに跳ね返る仕組み

業務システムの費用は開発時より運用・改修フェーズで積み上がります。カプセル化で内部を隠し、ポリモーフィズムで拡張点を用意しておくと、機能追加のたびに既存コードへ手を入れる範囲が狭まり、改修時の影響調査とテストの工数が下がる構造です。逆に、状態が各所へ漏れ、種別分岐がコード全体に散った設計は、1つの変更が広範囲へ波及し、改修のたびに回帰テストの範囲が膨らみます。設計品質は、初期費用ではなく総保有コストで評価するのが妥当です。一創では、既存システムの改修・保守や社内での内製化を支える保守運用・内製化支援を通じて、こうした設計の見直しから開発体制づくりまで伴走しています。

過剰な抽象化を避け、設計への投資を見合わせる判断の目安と具体例

一方で、オブジェクト指向の抽象化を効かせすぎると、読むために追う階層が増えて逆に保守しにくくなります。使い捨てのスクリプトや、仕様が固まっていて拡張予定のない小さな処理では、インタフェースや継承階層を作り込む価値は薄く、素直な手続き型で書くほうが早く安く仕上がります。抽象化は将来の変更に備える保険であり、変更が来ないと分かっているところに保険料は払いません。拡張点を用意するのは、変更が現実に予想される箇所へ絞ります。

よくある質問

オブジェクト指向の学習や実装でつまずきやすい点を、検索されやすい質問に沿って簡潔に答えます。

オブジェクト指向の三大要素とは何ですか？

カプセル化・継承・ポリモーフィズムの3つです。カプセル化は内部状態を隠してデータの整合性を守り、継承は共通コードを親クラスにまとめて重複を減らし、ポリモーフィズムは呼び出し側を変えずに振る舞いを差し替えます。三者は役割が分かれており、実装ではまずカプセル化で公開範囲を絞ることから始めると効果を実感しやすくなります。

オブジェクト指向と手続き型の違いは何ですか？

データと処理の置き場所が違います。手続き型はデータをグローバルに置き、関数が外から書き換えます。オブジェクト指向はデータと処理を同じオブジェクトへ閉じ込め、外部からは公開メソッド経由でしか触れません。この違いにより、規模が大きくなったとき変更の影響範囲をオブジェクト内部に限定できます。

継承と合成（コンポジション）はどちらを使うべきですか？

再利用が目的なら合成を第一候補にします。継承を選ぶのは、子が親の一種だと型として言い切れる is-a 関係が成立する場合です。再利用したいだけで無関係なクラスを継承すると、親の変更が子を壊す密結合を生みます。合成は持つ相手を後から差し替えやすく、テストもしやすい利点があります。

ポリモーフィズムはどんな場面で使いますか？

型ごとに処理を分ける条件分岐が長くなってきた場面です。種別を見て振る舞いを切り替える分岐を、インタフェースと実装クラスへ置き換えると、新しい種別はクラスを1つ足すだけで済み、既存コードを触りません。ただし種別が2つで今後増えないと分かっているなら、無理に抽象化せず分岐のままにする判断も妥当です。

オブジェクト指向はどの言語で学ぶとよいですか？

アクセス修飾子や型の宣言が明示的なJavaやC#は、三本柱の概念と実装の対応を確認しやすい言語です。PythonやRubyでも同じ概念を学べますが、修飾子の扱いが緩いため、まず明示的な言語で仕組みを押さえてから動的な言語へ移ると、隠蔽や型の置換の意味が腹落ちしやすくなります。

関連記事

• カプセル化とは何か？オブジェクト指向における基本概念を解説：三本柱の土台であるカプセル化を、アクセス修飾子と実装例まで掘り下げた記事です。
• カプセル化とポリモーフィズム：継承との違いと役割：三本柱それぞれの違いと役割を、具体例を交えて整理した記事です。
• データ指向アプリケーションデザインの基本原則と利点：オブジェクト指向と対になる、データ中心の設計アプローチを解説した記事です。