🪙

オブジェクト指向とは何か

に公開
Python
オブジェクト指向
tech

オブジェクト指向とは

オブジェクト指向（Object Oriented Programming, OOP）とは、**「現実世界のモノや概念をプログラム上の"オブジェクト"として捉え、設計・実装する考え方」**である。
これにより、再利用性・保守性・拡張性の高いソフトウェア開発が可能となる。

オブジェクト指向の3大要素

要素 概要 例（Python）
カプセル化 データ（属性）と処理（メソッド）を1つの単位（クラス）にまとめる class Circle: ...
継承 既存クラスの機能を引き継ぎ、新たなクラスを作成できる class Dog(Animal): ...
ポリモーフィズム 同じインターフェースで異なる実装を使い分けられる def draw(shape): ...

オブジェクト指向のメリット

  • 再利用性：既存のクラスを使い回せる
  • 保守性：修正箇所が限定される
  • 拡張性：新しい機能追加が容易

歴史と背景

オブジェクト指向という考え方は、単一の出来事や発明によって生まれたものではなく、プログラミングの進化の過程で徐々に形成されてきました。

時代区分 主要な出来事・概念 技術的な課題 (当時のプログラマの悩み) オブジェクト指向による解決の方向性
黎明期 (1960年代) Simula言語の登場 複雑な現実世界のシミュレーションの難しさ: 現実世界の事象や相互作用を、当時の手続き型言語でそのまま表現するのは非常に煩雑でした。例えば、複数の「顧客」が「窓口」で「順番待ち」をするような状況を、データと手続きを個別に管理しながら記述するのは困難でした。 Simulaは「オブジェクト」という概念を導入し、データとそのデータを操作する手続きをひとまとめに扱うことを可能にしました。これにより、シミュレーション対象（顧客、窓口など）をより直感的にプログラム上で表現できるようになりました。これが後の「クラス」の原型となります。
アラン・ケイによる初期の着想 プログラムの硬直性と再利用性の低さ: 一度書いたプログラムの一部を、別の目的で再利用したり、少し変更して使ったりすることが難しい状況でした。特定の処理に特化したサブルーチンはありましたが、データ構造と密接に結びついていることが多く、汎用性に欠けていました。 「メッセージング」という考え方。オブジェクト同士が互いに指示（メッセージ）を送り合うことで協調動作するというアイデアは、個々のオブジェクトの独立性を高め、システムの柔軟性向上に繋がると期待されました。
発展期 (1970年代) Smalltalkの開発 大規模で複雑なGUIアプリケーション開発の困難: マウス操作やウィンドウ表示といった、当時としては新しい対話的なインターフェース（GUI）が登場しましたが、これを実現するためのソフトウェア構造は複雑になりがちでした。イベント処理や画面要素の管理など、多くの要素が絡み合い、「スパゲッティコード」化しやすい状況でした。 「すべてがオブジェクトである」という徹底したオブジェクト指向により、GUIの構成要素（ウィンドウ、ボタン、カーソルなど）もオブジェクトとして扱えるようになりました。これにより、各要素の役割分担が明確になり、見通しの良い設計が可能になりました。MVC（Model-View-Controller）アーキテクチャの原型もこの時期に生まれています。
ソフトウェア危機 「書けば書くほど複雑怪奇になるコード」との戦い: プログラムの規模が大きくなるにつれて、どこを修正すればどこに影響が出るのか予測困難になり、機能追加やバグ修正が指数関数的に難しくなりました。データがグローバルに共有され、意図しない箇所で変更されてしまう問題（副作用）も頻発しました。 カプセル化の重要性が認識されました。データとその操作をオブジェクト内に閉じ込めることで、外部からの意図しないアクセスを防ぎ、変更の影響範囲を限定しようとしました。これにより、モジュール性（部品としての独立性）が高まり、大規模開発における複雑さを抑制する効果が期待されました。
普及期 (1980年代) C++の登場 実行速度と抽象化のトレードオフ: SimulaやSmalltalkのような純粋なオブジェクト指向言語は、柔軟性が高い反面、当時のハードウェアでは実行速度が遅いという課題がありました。C言語のような手続き型言語の高速性は魅力でしたが、大規模開発には抽象化の仕組みが不足していました。 C++は、C言語の実行効率を保ちつつ、クラス、継承、ポリモーフィズムといったオブジェクト指向の強力な抽象化メカニズムを取り入れました。これにより、パフォーマンスが要求されるシステム開発においても、オブジェクト指向の恩恵を受けられる道が開かれました。
オブジェクト指向方法論の進展 「オブジェクト指向でどう設計すれば良いのか？」という手探り状態: オブジェクト指向という概念は魅力的でしたが、それを実際の設計にどう落とし込むのか、具体的な設計手法やノウハウが不足していました。「とりあえずクラスを作ってみる」だけでは、結局複雑なシステムは作れませんでした。 OOA（オブジェクト指向分析）やOOD（オブジェクト指向設計）といった設計方法論が研究され始めました。現実世界の問題をオブジェクトの観点から分析し、クラス間の関係性や責務を明確にしていくことで、より体系的な設計が可能になることを目指しました。
成熟期 (1990年代以降) Javaの登場 プラットフォーム依存とメモリ管理の煩雑さ: C++は強力でしたが、異なるOSやCPUでプログラムを動かすためには再コンパイルやコード修正が必要（プラットフォーム依存）でした。また、手動でのメモリ管理（確保と解放）は、メモリリークやダングリングポインタといった厄介なバグの原因となり、開発者の大きな負担でした。 Javaは「Write Once, Run Anywhere（一度書けばどこでも動く）」を掲げ、JVM（Java仮想マシン）上で動作することでプラットフォーム非依存性を実現しました。また、ガベージコレクションによる自動メモリ管理機能を搭載し、開発者をメモリ管理の苦労から解放しました。これにより、より生産性の高い開発が可能になりました。
デザインパターンとUML 「よくある設計問題」に対する「車輪の再発明」の繰り返し: 経験豊富な開発者は、特定の問題に対して効果的な設計パターンを経験的に知っていましたが、それらが共有されず、多くの開発者が同じような問題で悩み、同じような解決策を個別に再発明していました。また、設計の意図を他者に伝える共通の語彙や図法も不足していました。 GoFのデザインパターンは、オブジェクト指向設計における典型的な問題と、その実証済みの解決策をカタログ化したものです。これにより、設計ノウハウが共有され、再利用可能になりました。UMLは、システムの構造や振る舞いを視覚的に表現するための標準的なモデリング言語として、設計者間のコミュニケーションを円滑にしました。
その他のオブジェクト指向言語の発展 特定用途への最適化や、より簡潔な記述、開発効率の追求: JavaやC++は強力ですが、より手軽にスクリプトを書きたい、特定のドメイン（Web開発など）に特化した機能が欲しい、といった多様なニーズが存在しました。 PythonやRubyのような動的型付け言語は、迅速なプロトタイピングやスクリプティングに適した手軽さを提供しました。C#はWindowsプラットフォームとの親和性を高め、SwiftやKotlinはモバイルアプリ開発の効率化を目指すなど、それぞれの言語が特定の強みを持って発展し、オブジェクト指向の適用範囲を広げていきました。

このように、オブジェクト指向は、より効率的で、柔軟性、再利用性、保守性の高いソフトウェア開発を目指す中で、多くの先駆者たちの知恵と経験が集積されて発展してきた考え方です。それぞれの時代でプログラマーが直面した具体的な課題を克服する過程で、オブジェクト指向の各要素が洗練され、体系化されてきました。

図解：オブジェクト指向のイメージ

オブジェクト指向の基本的な考え方は、現実世界の「モノ」や「概念」を、プログラムの世界で「オブジェクト」として表現することです。

例えば、現実世界の「車」を考えてみましょう。

この「車」は、色、速度、メーカーといった「属性（データ）」と、走る、止まる、曲がるといった「振る舞い（操作）」を持っています。

オブジェクト指向では、まず「車の設計図」にあたるクラスを定義します。

+---------------------------+      +---------------------------+
|   クラス：Car (設計図)    |      |   現実世界の車 (概念)     |
+---------------------------+      +---------------------------+
| 属性 (データ):             |      | 特徴:                     |
|   - 色 (color)            |      |   - 赤色                  |
|   - 現在速度 (currentSpeed) |      |   - 時速60km              |
|   - メーカー (manufacturer) |      |   - トヨタ                |
+---------------------------+      +---------------------------+
| 操作 (メソッド):           |      | 動作:                     |
|   - 加速する (accelerate)   |      |   - アクセルを踏む          |
|   - 減速する (decelerate)   |      |   - ブレーキをかける        |
|   - 方向転換する (turn)     |      |   - ハンドルを切る          |
+---------------------------+      +---------------------------+

そして、この設計図（クラス）に基づいて、具体的な「車」の**オブジェクト（実体）**を生成します。

+-----------------------------+     +-----------------------------+
| オブジェクト1：myCar (赤い車) |     | オブジェクト2：yourCar (青い車) |
+-----------------------------+     +-----------------------------+
| 属性:                       |     | 属性:                       |
|   color = "赤"              |     |   color = "青"              |
|   currentSpeed = 0          |     |   currentSpeed = 0          |
|   manufacturer = "トヨタ"   |     |   manufacturer = "ホンダ"   |
+-----------------------------+     +-----------------------------+
| 操作:                       |     | 操作:                       |
|   myCar.accelerate(20)      |     |   yourCar.accelerate(30)      |
|   myCar.turn("右")          |     |   yourCar.decelerate(10)    |
+-----------------------------+     +-----------------------------+

カプセル化のイメージ:

オブジェクトは、自身のデータ（属性）とそれを操作するメソッド（操作）をひとまとめに隠蔽します（カプセル化）。外部からは、公開されたメソッドを通じてのみデータにアクセスできます。これにより、内部構造を知らなくても安全にオブジェクトを利用できます。

+-----------------------------------+
| Carオブジェクト                   |
| +-------------------------------+ |
| | 内部データ (非公開)           | |
| |   - エンジン部品              | |
| |   - 燃料残量                | |
| +-------------------------------+ |
| +-------------------------------+ |
| | 公開インターフェース (メソッド) | |
| |   - アクセルを踏む()          | |
| |   - ブレーキをかける()        | |
| |   - ハンドルを切る()          | |
| +-------------------------------+ |
+-----------------------------------+
      ^
      | (外部からの操作はここまで)

継承のイメージ:

「車」クラスを元に、「トラック」クラスや「スポーツカー」クラスといった、より専門的なクラスを作成できます（継承）。「トラック」は「車」の基本的な機能（走る、止まる）を引き継ぎつつ、「荷物を積む」という独自の機能を追加できます。

ポリモーフィズムのイメージ:

例えば「音を出す」という同じ命令でも、犬オブジェクトなら「ワン！」、猫オブジェクトなら「ニャー」と、オブジェクトの種類によって実際の振る舞いが変わります。これがポリモーフィズム（多態性）です。

+-------------------+     +-----------------+     +-----------------+
|   関数: makeSound(animal) | --> | 犬オブジェクト  | --> | 「ワン！」と鳴く |
+-------------------+     +-----------------+     +-----------------+
         |
         v
+-----------------+     +-----------------+
| 猫オブジェクト  | --> | 「ニャー」と鳴く |
+-----------------+     +-----------------+

このように、オブジェクト指向は、現実世界のモデルをプログラムに落とし込みやすく、部品（オブジェクト）の組み合わせでシステムを構築していくため、複雑なソフトウェアも整理しやすく、変更にも強い構造を作りやすいという利点があります。

設計原則とデザインパターン

オブジェクト指向設計を効果的に行うためには、先人たちが積み重ねてきた知見である「設計原則」と「デザインパターン」を理解し、活用することが重要です。

SOLID原則

SOLID原則は、オブジェクト指向設計における5つの重要な原則の頭文字をとったものです。これらの原則に従うことで、より理解しやすく、柔軟で、保守性の高いシステムを構築することができます。

原則 英語名 (頭文字) 概要 なぜ重要か
単一責任の原則 Single Responsibility Principle (SRP) 1つのクラスは1つの責任だけを持つべきである。つまり、クラスを変更する理由は1つだけであるべき。 クラスの凝集度を高め、関心を分離することで、理解しやすさ、テストの容易さ、変更の影響範囲の局所化につながる。
オープン・クローズドの原則 Open/Closed Principle (OCP) ソフトウェアの実体（クラス、モジュール、関数など）は、拡張に対して開いていて、修正に対して閉じているべきである。 既存のコードを変更せずに新機能を追加できるようにすることで、安定性を保ちつつ拡張性を高める。継承やインターフェース、ポリモーフィズムを利用して実現されることが多い。
リスコフの置換原則 Liskov Substitution Principle (LSP) サブタイプは、その基本型と置換可能でなければならない。つまり、親クラスのオブジェクトを参照している箇所で、そのサブクラスのオブジェクトに置き換えても、プログラムの動作が変わらないようにするべきである。 継承関係を正しく保ち、ポリモーフィズムを安全に利用できるようにする。サブクラスが親クラスの規約を破らないようにすることで、予期せぬ動作を防ぐ。
インターフェース分離の原則 Interface Segregation Principle (ISP) クライアントに、自身が利用しないメソッドへの依存を強制してはならない。つまり、大きなインターフェースを定義するのではなく、より小さく、特定のクライアント向けに特化したインターフェースを多数定義すべきである。 クラスが必要としないメソッドの実装を強制されることを防ぎ、クラス間の疎結合を促進する。インターフェースの凝集度を高め、再利用性と柔軟性を向上させる。
依存性逆転の原則 Dependency Inversion Principle (DIP) 上位モジュールは下位モジュールに依存すべきではない。両方とも抽象に依存すべきである。また、抽象は詳細に依存すべきではない。詳細は抽象に依存すべきである。 モジュール間の結合度を下げ、柔軟性と再利用性を高める。具体的な実装ではなく、抽象（インターフェースや抽象クラス）に依存することで、変更の影響を受けにくくする。依存性注入（DI）などのテクニックと関連が深い。

デザインパターン (GoFの23パターン)

デザインパターンは、オブジェクト指向設計において頻繁に現れる特定の問題に対する、再利用可能な解決策のカタログです。「GoF (Gang of Four)」と呼ばれる4人の著者によってまとめられた23の基本的なデザインパターンは、以下の3つのカテゴリに分類されます。

1. 生成に関するパターン (Creational Patterns)

オブジェクトの生成プロセスを抽象化し、柔軟性と再利用性を高めます。

パターン名 目的・概要
Abstract Factory 関連する一連のインスタンスを整合性を保ったまま「まとめて」生成するためのAPIを提供する。具体的なクラスを指定せずに、関連するオブジェクト群を生成できる。
Builder 複雑なオブジェクトの組み立て処理をステップごとに分離し、同じ組み立てプロセスで異なる表現のオブジェクトを生成できるようにする。
Factory Method オブジェクト生成のためのインターフェースを定義し、どのクラスのインスタンスを生成するかはサブクラスに決定させる。
Prototype 既存のインスタンスを複製（クローン）することによって新しいインスタンスを生成する。生成コストが高い場合や、動的にクラスを指定したい場合に有効。
Singleton あるクラスのインスタンスがプログラム全体で唯一であることを保証し、そのインスタンスへのグローバルなアクセスポイントを提供する。

2. 構造に関するパターン (Structural Patterns)

クラスやオブジェクトを組み合わせて、より大きな構造を形成する方法を扱います。

パターン名 目的・概要
Adapter 互換性のないインターフェースを持つクラス同士を、既存のクラスを変更することなく協調動作させるためのラッパーを提供する。
Bridge 「機能のクラス階層」と「実装のクラス階層」を分離し、それぞれを独立して拡張できるようにする。
Composite 個々のオブジェクト（葉）とオブジェクトの集合（枝）を同じように扱えるように、再帰的な木構造のコンポジションを構築する。
Decorator オブジェクトに動的に新しい機能を追加する。継承よりも柔軟に機能を拡張できる。
Facade 複雑なサブシステムに対するシンプルな統一インターフェースを提供する。サブシステムの複雑さを隠蔽し、利用しやすくする。
Flyweight 多数の小さなオブジェクトを効率的にサポートするために、共有可能な状態とそうでない状態を分離し、共有によってインスタンス数を減らす。
Proxy あるオブジェクトへのアクセスを制御するための代理オブジェクトを提供する。アクセス制御、遅延初期化、リモートオブジェクトの表現などに利用される。

3. 振る舞いに関するパターン (Behavioral Patterns)

オブジェクト間のアルゴリズムや責任の割り当てに関連するパターンです。

パターン名 目的・概要
Chain of Responsibility リクエストを処理できるオブジェクトが見つかるまで、複数のオブジェクトにリクエストを連鎖的に渡していく。
Command リクエスト（操作）をオブジェクトとしてカプセル化する。これにより、リクエストのパラメータ化、キューイング、ロギング、アンドゥ機能などを実現できる。
Interpreter ある言語の文法を定義し、その文法に基づいて文を解釈するインタープリタを構築する。
Iterator コレクションの内部表現を公開することなく、その要素に順番にアクセスする方法を提供する。
Mediator オブジェクト間の複雑な相互作用をカプセル化し、オブジェクト同士が直接参照しあうことなく協調動作できるようにする「調停者」を導入する。
Memento オブジェクトのカプセル化を破壊することなく、その内部状態を外部に保存し、後でその状態に戻せるようにする。アンドゥ機能の実装などに使われる。
Observer あるオブジェクト（Subject）の状態が変化したときに、それに依存する複数のオブジェクト（Observer）に自動的に通知し、更新できるようにする。イベント処理などで利用される。
State オブジェクトの内部状態に応じて、その振る舞いを変更できるようにする。状態遷移を明確に表現できる。
Strategy アルゴリズムのファミリーを定義し、それぞれをカプセル化して、動的にアルゴリズムを切り替えられるようにする。
Template Method アルゴリズムの骨格（テンプレート）をスーパークラスで定義し、具体的なステップの実装をサブクラスに遅延させる。処理の共通化と拡張性を両立する。
Visitor データ構造（オブジェクトの集まり）と、それに対する処理を分離する。データ構造を変更せずに新しい操作を追加できるようにする。

これらの原則とパターンは、オブジェクト指向設計の質を高めるための強力な道具となりますが、状況に応じて適切に適用することが重要です。闇雲に適用するのではなく、解決したい問題やシステムの特性を考慮して選択する必要があります。

参考文献

書籍

  • Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional. (邦訳: 本位田真一、吉田和樹監訳 (1995). オブジェクト指向における再利用のためのデザインパターン. ソフトバンククリエイティブ.)
  • Robert C. Martin (2017). Clean Architecture: A Craftsman's Guide to Software Structure and Design. Prentice Hall. (邦訳: 角征典、高木正弘訳 (2018). Clean Architecture 達人に学ぶソフトウェアの構造と設計. アスキードワンゴ.)
  • Robert C. Martin (2002). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. (邦訳: 瀬谷啓介訳 (2003). アジャイルソフトウェア開発の奥義 オブジェクト指向開発の神髄と匠の技. SBクリエイティブ.)
  • 結城浩 (2004). Java言語で学ぶデザインパターン入門. ソフトバンククリエイティブ.
  • 平澤章 (2017). オブジェクト指向でなぜつくるのか 第3版 知っておきたいOOP、設計、アジャイル開発の基礎知識. 日経BP.

Webサイト・技術ブログ

このように、オブジェクト指向は「現実世界のモノの捉え方」をプログラムに持ち込むことで、複雑なソフトウェアをシンプルかつ強力に設計・実装できる手法である。
表や図を活用し、要点をまとめることで理解しやすくなる。

Discussion