オブジェクト指向はデザインパターンから理解する
Copyright © 2026 LWP 山中 一弘
本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。
記事要約
オブジェクト指向は、クラス、インスタンス、継承、多態性、カプセル化といった用語だけを覚えても、なかなか使えるようになりません。
理由は単純です。それらはオブジェクト指向そのものというより、オブジェクト指向で設計するための道具だからです。道具の名前を知ることと、道具を使ってアプリケーションを組み立てることは別の学習です。
C言語でも同じことが起きます。ポインタ、構造体、関数を学んでも、それだけでコンパイラやOSやデバイスドライバを書けるわけではありません。それらを使って問題を解くには、アルゴリズム、データ構造、対象領域の知識が必要になります。
オブジェクト指向でも、クラスや継承を覚えたあとに学ぶべきものがあります。その入口として有効なのがデザインパターンです。
デザインパターンは、オブジェクトの分け方、責務の置き方、変更点の閉じ込め方を学ぶための教材です。オブジェクト指向が分からないと感じる人は、言語機能の暗記から一歩進んで、デザインパターンを通じて「どう組み合わせて問題を解くのか」を学ぶと理解しやすくなります。
本記事の対象とゴール
本記事は、オブジェクト指向の入門用語を学んだものの、実際の設計やコードでどう使えばよいのか分からない人を対象にしています。
対象読者は、たとえば次のような人です。
クラスとインスタンスの説明は読んだが、実務コードでの使いどころが分からない人
継承や多態性の意味は分かるが、設計にどう効くのかが分からない人
オブジェクト指向の説明が比喩で終わってしまい、実装に進めない人
VBA、C言語、Python、JavaScriptなどを学びながら、設計の考え方を整理したい人
本記事のゴールは、オブジェクト指向を「言語機能の集まり」としてではなく、「複雑なアプリケーションを現実的に扱うための設計道具」として理解することです。
先に結論
オブジェクト指向が分かりにくい理由は、言語機能の理解と、設計手法の理解が混同されやすいからです。
クラス、インスタンス、継承、多態性、カプセル化は大切です。しかし、それらは道具です。道具を覚えただけでは、よい設計はできません。
C言語でポインタ、構造体、関数を覚えたあとに、アルゴリズムやデータ構造を学ぶ必要があるのと同じです。オブジェクト指向では、言語機能を覚えたあとに、オブジェクトの組み合わせ方を学ぶ必要があります。
その入口がデザインパターンです。
デザインパターンを学ぶことで、継承や多態性が単なる用語ではなく、変更に強い構造を作るための具体的な手段として見えてきます。
オブジェクト指向の説明は、なぜ途中で止まりやすいのか
オブジェクト指向の入門では、よく「たい焼きの型と実物」のような比喩が使われます。
型がクラスで、できあがったたい焼きがインスタンスです。この説明は、クラスとインスタンスの入口としては分かりやすいものです。
しかし、この比喩だけでは、オブジェクト指向でアプリケーションを作る方法までは分かりません。
なぜなら、この説明は「道具の形」を説明しているだけだからです。クラスとは何か、インスタンスとは何かを説明していても、どのように責務を分けるのか、どのように変更に強くするのか、どのように処理を差し替え可能にするのかまでは説明していません。
そのため、入門説明を読んだ人は、用語は知っているのにコードを書けない状態になりやすいのです。
これは学習者の理解力の問題ではありません。説明されている範囲が、そもそも設計の入口まで届いていないのです。
C言語のポインタ、構造体、関数で考える
オブジェクト指向の分かりにくさは、C言語に置き換えると理解しやすくなります。
C言語には、ポインタ、構造体、関数という重要な道具があります。
ポインタを使えば、メモリ上の位置を扱えます。構造体を使えば、複数の値をまとまりとして扱えます。関数を使えば、処理を分割できます。
この3つを組み合わせると、非常に多くのことができます。構造体をポインタでつなげば、リストや木構造を作れます。関数を再帰的に呼び出せば、構文木の処理や探索処理を書けます。メモリやI/Oを扱えば、OSやデバイスドライバのような低レイヤーの処理にも近づけます。
しかし、ポインタ、構造体、関数の文法を覚えただけで、すぐにコンパイラを書けるわけではありません。
コンパイラを書くには、字句解析、構文解析、構文木、記号表、コード生成といった考え方が必要です。OSを書くには、プロセス、メモリ管理、割り込み、ファイルシステムといった対象領域の知識が必要です。
道具の理解と、道具を使って構築する方法の理解は違います。
オブジェクト指向でも、まったく同じことが起きています。
言語機能は目的ではなく道具である
オブジェクト指向では、継承、多態性、カプセル化、抽象データ型、参照型などがよく説明されます。
これらは重要です。ただし、これら自体が目的ではありません。
継承は、共通部分をまとめたり、抽象的な型として扱ったりするための道具です。多態性は、呼び出し側が具体的な実装を知らなくても処理を呼べるようにする道具です。カプセル化は、内部状態や実装詳細を外から直接触らせないための道具です。
つまり、これらは「複雑なアプリケーションを扱いやすくするための仕組み」です。
オブジェクト指向を理解するには、それぞれの機能を単独で覚えるだけでは足りません。その機能が、どんな設計上の問題を解くためにあるのかを考える必要があります。
たとえば、多態性を「同じメソッド名で違う動きをすること」とだけ覚えると、説明はそこで止まります。
しかし、多態性を「呼び出し側を安定させ、変更される処理を差し替え可能にする仕組み」と捉えると、設計上の意味が見えてきます。
オブジェクト指向は何を簡単にするのか
C言語でできることは、理屈の上ではアセンブラでもできます。
それでもC言語には価値があります。なぜなら、アセンブラでも原理的にはできることを、高級言語として現実的に書けるようにしたからです。
オブジェクト指向も同じです。
オブジェクト指向でできることの多くは、手続き型言語でも実現できます。構造体を作り、関数を分け、関数ポインタや分岐を使えば、似たような構造を自前で作ることはできます。
しかし、それを大規模なアプリケーションで継続的に行うのは難しくなります。
変更が増える。処理の差し替えが増える。対象データが増える。似た処理が増える。開発者が増える。仕様変更が続く。
こうした状況で、どこを変えればよいのか、どこに責務があるのか、何を差し替えればよいのかが分からなくなると、アプリケーションはすぐに保守しにくくなります。
オブジェクト指向は、この複雑さを現実的に扱うための考え方です。
デザインパターンは、道具の使い方を学ぶ教材である
では、言語機能を覚えたあとに何を学べばよいのでしょうか。
入口として有効なのがデザインパターンです。
デザインパターンは、オブジェクトの組み合わせ方と、その組み合わせがどんな問題に効くのかを整理したものです。
ここで大切なのは、パターン名を暗記することではありません。
重要なのは、パターンを通じて次のような設計感覚を身につけることです。
どの責務をどのオブジェクトに置くのか
変更されやすい処理をどこに閉じ込めるのか
呼び出し側を安定させるには、どこを抽象化するのか
生成処理と利用処理をどのように分けるのか
状態変化や通知をどのように整理するのか
たとえば、Strategyパターンは、処理の違いをオブジェクトとして差し替える考え方を教えてくれます。
Observerパターンは、ある状態が変わったときに、関係する相手へ通知する構造を教えてくれます。
Factory MethodやAbstract Factoryは、生成する処理と利用する処理を分ける考え方を教えてくれます。
これらを学ぶと、継承や多態性やインターフェースが、単なる文法ではなく、変更しやすい構造を作るための道具として見えてきます。
「クラスを作る」から「責務を分ける」へ進む
オブジェクト指向を学ぶとき、最初は「クラスを作る」ことに意識が向きます。
しかし、実務で重要なのは、クラスを作ることそのものではありません。
重要なのは、責務を分けることです。
どの情報をどこが持つのか。どの判断をどこが行うのか。どの処理をどこに閉じ込めるのか。どの部分を変更可能にして、どの部分を安定させるのか。
このような判断ができるようになると、オブジェクト指向は急に実用的になります。
逆に、責務の分け方を学ばないままクラスだけを増やすと、ただ処理が散らばっただけのコードになります。
オブジェクト指向は、クラスをたくさん作る技術ではありません。責務を整理し、変更に強い構造を作るための技術です。
初学者はどの順番で学べばよいか
オブジェクト指向を学ぶ順番としては、次の流れが現実的です。
クラス、インスタンス、メソッド、プロパティの基本を理解する
カプセル化、継承、多態性の文法を理解する
小さな例で、処理の差し替えや責務分離を試す
Strategy、Observer、Factoryなどの基本的なデザインパターンを学ぶ
実務のコードで、どの変更点をどこに閉じ込めるかを考える
継承より委譲、具象より抽象、巨大クラスより責務分離を意識する
この順番で学ぶと、用語の暗記で止まりにくくなります。
特に大切なのは、3番目以降です。小さな例でよいので、「同じ呼び出し方で処理を差し替える」「生成処理を別の場所へ逃がす」「通知先を直接固定しない」といった構造を実際に書いてみることです。
その経験があると、デザインパターンの説明が単なるカタログではなく、実感のある設計手法として読めるようになります。
まとめ
オブジェクト指向が分かりにくいのは、クラスや継承の説明が間違っているからではありません。
それらの説明だけでは、設計の入口まで届かないからです。
クラス、インスタンス、継承、多態性、カプセル化は、オブジェクト指向を支える道具です。しかし、道具を知ることと、道具を使ってアプリケーションを設計することは別です。
C言語でポインタ、構造体、関数を学んだあとに、アルゴリズムやデータ構造を学ぶ必要があるのと同じように、オブジェクト指向では言語機能を学んだあとに、オブジェクトの組み合わせ方を学ぶ必要があります。
その入口として、デザインパターンは有効です。
オブジェクト指向が分からないと感じるときは、クラスとインスタンスの比喩で止まらず、デザインパターンを通じて「責務をどう分けるか」「変更点をどこに閉じ込めるか」「呼び出し側をどう安定させるか」を学ぶとよいでしょう。
オブジェクト指向理解への第一歩は、言語機能だけでなく、デザインパターンも合わせて学ぶことです。
出典メモ
本記事は、Dropbox Paper「2019-04-25 雑談 オブジェクト指向がわからない理由（とワイが思うこと）」を元資料として、公開記事向けに構成・表現・見出しを再設計したものです。
元資料では、C言語のポインタ、構造体、関数によるパラダイム変化と、オブジェクト指向における継承、多態性、抽象データ、参照型の位置づけを対比しながら、オブジェクト指向理解にはデザインパターンの学習が有効である、という主旨が述べられています。