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

オブジェクト指向プログラミング（オブジェクトしこうプログラミング、英: object-oriented programming、略語:OOP）は、オブジェクト指向に基づいたコンピュータプログラミング手法である。オブジェクトは概ねデータ（変数、プロパティ）とコード（関数、メソッド）の複合体を指す見解で一致しているが、その詳細の解釈は様々である。オブジェクト指向のプログラムはこのオブジェクトの集合として組み立てられる事になるが、その実装スタイルもまた様々である。

オブジェクト指向プログラミングという言葉自体は、計算機科学者アラン・ケイによって生み出されている。1967年公開の言語「Simula67」の設計に印象を受けたケイが咄嗟に口にしたとされるこの造語は、彼が1972年から公開を始めた「Smalltalk」の設計を説明する中で初めて用いられている。なおケイが示したメッセージパッシングを中心にするオブジェクト指向は広く認知される事はなく、オブジェクトというプログラム概念を注目させるだけに留まっている。同時にケイの手から離れたオブジェクト指向は抽象データ型を中心にした解釈へと推移していき、1983年に計算機科学者ビャーネ・ストロヴストルップが公開した「C++」が契機になって、日本では一般にOOPの三大要素と呼ばれるカプセル化、継承、多態性といったパラダイムが確立されている。

特徴

現行のオブジェクト指向プログラミングは事実上、1974年にバーバラ・リスコフらが提唱した抽象データ型を基底概念にする方向性で定着している。抽象データ型のプログラム実装スタイルを具体的に規定したものが1～3であり、日本では一般に三大要素と呼ばれている。これに沿った言語仕様を備えたプログラミング言語がオブジェクト指向準拠と判別されている。4と5は、アラン・ケイが重視する元祖的なコンセプトであり現在では主流から外れているが、オブジェクト指向の源流思想として蛇足ながら紹介を加える。

1. カプセル化（encapsulation）
2. 継承（inheritance）
3. 多態性（polymorphism）
4. メッセージ・パッシング（message passing）
5. 遅延バインディング（late binding）

カプセル化

一定の関連性を持つデータ（変数、プロパティ）と、それらを操作するコード（関数、プロシージャ）をひとまとめにしてオブジェクトとし、外部に対して必要とされるデータとコードのみを公開し、その他は内部に隠蔽する仕組みがカプセル化と呼ばれる。オブジェクトが持つコードは一般に「メソッド」と呼ばれる。オブジェクトの設計は単一責任の原則に従い、一つの閉包機能をなすデータ構成とそれに関連したメソッドを定義するのが基本になる。公開されたデータは外部のメソッドから直接参照ないし変更する事できる。公開されたメソッドは同様に外部のメソッドから直接呼び出す事ができる。隠蔽されたデータとメソッドは外部からアクセスできず、これは情報隠蔽と呼ばれる。

継承

既存オブジェクトのデータ構成とメソッド構成を引き継いで、新しい派生オブジェクトを定義する仕組みが継承と呼ばれる。引き継ぐ際には新たなデータとメソッドを自由に追加できるので、派生オブジェクトの構成は既存内容＋追加内容になる。継承構造は、既存束縛で真になる式は派生束縛でも真になるというリスコフの置換原則を遵守する。オブジェクトはソースコード上ではクラスとして定義されるので、継承元の親クラスはスーパークラス、継承先の子クラスはサブクラスと呼ばれる。クラスは自身のスーパークラスを複数個指定する事もできる。一つのスーパークラスを継承するのは単一継承、複数のスーパークラスを継承してそれぞれの構成内容を引き継ぐのは多重継承と呼ばれる。継承とは本質的に異なるが、多重の仕組みは後述のインターフェースの実装で重視されておりインターフェース分離の原則に活用されている。

多態性

異なる種類のオブジェクトに同一の操作インターフェースを持たせる仕組みが多態性と呼ばれる。オブジェクト指向下の多態性は、クラスの派生関係またはオブジェクトの動的バインディングを利用した実行時変化プロセスであるサブタイピングを指す。サブタイピング（派生型付け）は仮想関数、多重ディスパッチ、動的ディスパッチの三手法に分類される。最もよく知られる仮想関数は多態性と同義に説明される事が多い。仮想関数は、メソッドが所属するクラスの派生関係のみに焦点を当てたシングルディスパッチであり、スーパークラス抽象メソッドへの呼び出しから、その実行時のサブクラス実装メソッドに多方向分岐させるプロセスを指す。その際はVtableと呼ばれる関数へのポインタに近い仕組みが用いられる。抽象メソッドの使用は依存性逆転の原則に準じたものであり、それを中継点にした具体的メソッドの実装は開放閉鎖の原則を体現するものである。多重ディスパッチは、メソッドが所属するクラスの派生関係に加えて、メソッドの各引数のクラスの派生関係にも注目した形態である。各引数は実行時に型ダウンキャストされて、その引数の型パターンに対応したルーチンに分岐する。メソッド所属クラスの派生関係が絡まない場合は単一引数だとシングルディスパッチになる。多重ディスパッチの中でもプロセス分岐に関与するクラスが二つに限定されたものはダブルディスパッチと個別定義されている。動的ディスパッチは、プロトタイプベースのOOPで用いられるものであり、実行時におけるオブジェクトのメソッド参照の切り替えカスタマイズによるプロセス変化を指す。また、クラスベースのOOPでもクラスの定義内容を操作できるリフレクション機能によってこれが再現される事もある。

メッセージ・パッシング

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages. （さながら生物の細胞、もしくはネットワーク上の銘々のコンピュータ、それらはただメッセージによって繋がり合う存在、僕はオブジェクトをそう考えている） — Alan Kay

... each object could have several algebras associated with it, and there could be families of these, and that these would be very very useful. （銘々のオブジェクトは自身に伴う幾つかの「代数」を持つ、またそれらの家族たちもいるかもしれない、それらは極めて有用になるだろう） — Alan Kay

The Japanese have a small word - ma ... The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. （日本語には「間」という言葉がある・・・成長的なシステムを作る鍵とは内部の特徴と動作がどうあるべきかよりも、それらがどう繋がり合うかをデザインする事なんだ） — Alan Kay

遅延バインディング

I realized that the cell/whole-computer metaphor would get rid of data, ... （僕はこう気付いた、細胞であり全体でもあるコンピュータメタファーはデータを除去するであろうと、） — Alan Kay

... there were two main paths that were catalysed by Simula. The early one (just by accident) was the bio/net non-data-procedure route that I took. The other one, which came a little later as an object of study was abstract data types, and this got much more play. （Simulaを触媒にした二本の道筋があった。初めの一本は細胞組織的な非データ手法、僕が選んだ方だ。少し遅れたもう一本は抽象データ型、こっちの方がずっと賑わってるね。） — Alan Kay

歴史

オブジェクト指向プログラミングという考え方が生まれた背景には、計算機の性能向上によって従来より大規模なソフトウェアが書かれるようになってきたということが挙げられる。大規模なソフトウェアが書かれコードも複雑化してゆくにつれ、ソフトウェア開発コストが上昇し、1960年代には「ソフトウェア危機 (software crisis)」といったようなことも危惧されるようになってきた。そこでソフトウェアの再利用、部品化といったようなことを意識した仕組みの開発や、ソフトウェア開発工程の体系化（ソフトウェア工学 (software engineering) の誕生）などが行われるようになった。

このような流れの中で、プログラムを構成するコードとデータのうち、コードについては手続きや関数といった仕組みを基礎に整理され、その構成単位をブラックボックスとすることで再利用性を向上し、部品化を推進する仕組みが提唱され構造化プログラミング (structured programming) として1967年にエドガー・ダイクストラ (Edsger Wybe Dijkstra) らによってまとめあげられた（プログラミング言語の例としてはPascal 1971年）。なお、それに続けて「しかしデータについては相変わらず主記憶上の記憶場所に置かれている限られた種類の基本データ型の値という比較的低レベルの抽象化から抜け出せなかった。これはコードはそれ自身で意味的なまとまりを持つがデータはそれを処理するコードと組み合わせないと十分に意味が表現できないという性質があるためであった。」といったように、ほぼ間違いなく説明されている。

そこでデータを構造化し、ブラックボックス化するために考え出されたのが、データ形式の定義とそれを処理する手続きや関数をまとめて一個の構成単位とするという考え方でモジュール (module) と呼ばれる概念である（プログラミング言語の例としてはModula-2 1979年）。しかし定義とプログラム内の実体が一対一に対応する手続きや関数とは異なり、データはその形式の定義に対して値となる実体（インスタンスと呼ばれる）が複数存在し、各々様々な寿命を持つのが通例であるため、そのような複数の実体をうまく管理する枠組みも必要であることがわかってきた。そこで単なるモジュールではなく、それらのインスタンスを整理して管理する仕組み（例えばクラスとその継承など）まで考慮して生まれたのがオブジェクトという概念である（プログラミング言語の例としては1967年のSimula 67）。

Simulaのオブジェクトとクラスというアイデアは異なる二つの概念に継承される。一つはシステム全てをオブジェクトの集合と捉え、オブジェクトの相互作用をメッセージに喩えた「オブジェクト指向」である。オブジェクト間の相互作用をメッセージの送受と捉えることで、オブジェクトは受信したメッセージに見合った手続き単位（≒関数）を自身で起動すると考える。結果オブジェクトは自身の持つ手続きのカプセル化を行うことができ、メッセージが同じでもレシーバオブジェクトによって行われる手続きは異なる――多相性（ポリモーフィズム）を実現した（このメッセージを受け実行される手続き単位は、メッセージで依頼されたことを行うための「手法」の意味でメソッドと呼ばれる）。この思想に基づき作られたのがSmalltalk（1972年）であり、オブジェクト指向という言葉はこのときアラン・ケイによって作られた。

一方、Smalltalkとは別にSimulaの影響を受け作られたC++（1979年）は抽象データ型のスーパーセットとしてのクラス、オブジェクトに注目し、オブジェクト指向をカプセル化、継承、多相性をサポートするものと再定義した（その際、実行時速度重視およびコンパイラ設計上の制約により、変数メタファである動的束縛の特徴は除外された）。これらは当初抽象データ型、派生、仮想関数と呼ばれ、オブジェクトのメンバ関数を実体ではなくポインタとすることで、継承関係にあるクラスのメンバ関数のオーバーライド（上書き）を可能にしたことで、多相性を実現した（この流儀ではメッセージメタファはオブジェクト指向に必須ではないものと定義し、オブジェクトの持つ手続きをメソッドとは呼ばずメンバ関数と呼ぶ）。この他、Smalltalkにある動的束縛の類似的な機能としてオーバーロード（多重定義）が実装されている。

Smalltalkはこの「全てをオブジェクトとその相互作用で表現する」というデザインに立ち設計されたため、全てをファイルと捉えるファイル指向オペレーティングシステムからの脱却と、プログラムをフロー制御された手続きと捉える手続き型言語からの脱却が行われた。そのためSmalltalkは自身がオブジェクト指向オペレーティングシステムでもあること、メッセージ・パッシングなどの特徴を持った。これは当時のプログラム言語としては特異的であり、ガベージコレクタを必要とし、高度な最適化が試される前のバイトコードインタプリタで実行される処理の重さも手伝って先進的ではありながら普及しがたいものであると捉えられた。また、メッセージでの多相性は、変数へのオブジェクトの動的束縛が前提となるため、静的型チェック機構でのサポートが難しく、C++等の実行時性能重視の言語にとって実装から除外すべき特徴となった。

C++の創始者ビャーネ・ストロヴストルップは、Smalltalkが目指したある種の理想の追求には興味が無く、現用としての実用性を重視した。そのため、C++の再定義した「オブジェクト指向」は既存言語の拡張としてオブジェクト指向機能を実装できることでブレイクスルーを迎え急速に普及する。Smalltalkが単なるメソッドの動的呼び出しをメッセージ送信に見立て、呼び出すメソッドが見つからないときのみメッセージをハンドリングできるようにした「省コスト版」の機構を発明し以降それを採用するに至った経緯も手伝って、メッセージ送信という考え方はやや軽視されるようになり、オブジェクト指向とはC++の再定義したものと広く認知されるようになった。

1980年代後半に次々と生まれたオブジェクト指向分析・設計論は、Smalltalkを源流とするオブジェクト指向を基に組み立てられた。そのころSmalltalkは商用展開こそされていたが広く普及しているとは言えず、一般にはC++での実装が多くを占めた。しかしC++はSmalltalkと思想的にかなり異なる点や、同様のことを実現する際の実装面での複雑さや制約が問題とされた。このニーズを受けC++の提示した抽象データ型にクラスを適用する現実的な考え方と親しまれたALGOL系の構文を踏襲しつつ、内部的には柔軟なSmalltalkのオブジェクトモデルを採用し、メソッドなどの一部用語やリフレクション、実行時動的性などSmalltalk色も取り入れたJavaが注目を集めた（1995年に登場。元々はモバイル機器向け言語処理系として開発された）。程なくSmalltalkやSELFで達成された仮想マシン（バイトコードインタープリタ）高速化技術の転用により実用的速度を得、バランス感覚に長けたJavaの台頭によってオブジェクト指向開発に必要な要素の多くが満たされ、1990年代後半からオブジェクト指向は広く普及するようになった。

代表的なオブジェクト指向言語

オブジェクト指向言語の系譜

オブジェクト指向を総体的または部分的にサポートする機能を備えたプログラミング言語の公開は、1980年代後半から目立ち始めている。オブジェクト指向言語の分類法は複数あるが、Smalltalkをルーツにするメッセージパッシングの構文が重視されてるか否かでまず大別され、そうでないものは更にクラスベースとプロトタイプベースで分けられる事が多い。

クラスベースでは「C++」「Java」「C#」「Swift」がその代表とされる。プロトタイプベースでは「Python」「JavaScript」「Ruby」が有名である。メッセージ構文重視では「Smalltalk」「Objective-C」「Self」などがある。言語仕様の中でオブジェクト指向の存在感が比較的高い代表的なプログラミング言語は以下の通りである。

Simula 67 1967年

1962年に公開されたSimulaの後継版であり、クラスのプログラム概念を導入した最初の言語である。現実世界の擬似モデルを観測するシミュレーション・プログラム制作用に開発されたもので、クラスを実メモリに展開したオブジェクトは、その観測対象要素になった。Simulaのクラスは、プロシージャに専用変数と補助ルーチンを加えた小型モジュールに近いものであったが、継承と仮想関数という先進的な設計を備えていた事でオブジェクト指向言語の草分けと見なされるようになった。C++やJavaの源流になった。

Smalltalk 1972年

メッセージパッシングのプログラム概念を導入した最初の言語。数値、真偽値、文字列から変数、構造体、コードブロック、メタデータまでのあらゆる要素をオブジェクトとするデザインを編み出した最初の言語でもある。オブジェクト指向という言葉はSmalltalkの言語設計を説明する中で生み出された。オブジェクトの基礎的な振る舞いを規定する限られた予約語の他は、オブジェクトとメッセージのやり取りで制御構造を含めたあらゆるプロセスを表現出来た。専用のランタイム環境上で動作させる設計は、従来にない実行時多態性とセキュリティに繋がるモニタリングを実現した。これは後に仮想マシンと呼ばれるものとなり、JavaやC#に踏襲された。

C++ 1983年

C言語にクラスベースのオブジェクト指向を追加したもの。Simulaの影響を受けている。静的型付けのクラスの仕組みが備えられて、カプセル化、継承、多態性の三仕様を実装している。テンプレート機能、関数＆演算子オーバーロード、例外処理などのプログラミングパラダイムも導入された。元がC言語であるため、オブジェクト指向から逸脱したコーディングも多用できる点が物議を醸したが、その是非はプログラマ次第であるという結論に落ち着いた。

Objective-C 1984年

C言語にメッセージ構文重視のオブジェクト指向を追加したもの。こちらはSmalltalkの影響を受けており、それに準じたメッセージパッシングの仕組みが備えられた。メッセージを受け取るクラスの定義による静的型付けと共に、メッセージを委譲するオブジェクトの実行時決定による動的型付けも設けられている。オブジェクト指向的には前述のC++よりも正統であると見なされた。制御構文が追加され、メッセージ構文仕様もやや簡素化されるなど実践上の利便性が図られており、Smalltalkよりもコーディングし易くなった。

Object Pascal 1986年

Pascalにクラスベースのオブジェクト指向を追加したもの。

Eiffel 1986年

Pascalにクラスベースのオブジェクト指向を追加したもの。契約プログラミング方針と厳格な名前付け方針による静的型付けを重視した言語である。引数パターンによるオーバーローディングが除外されている。継承されたクラス名はその都度ユニーク名にクローンされて多重継承時の問題を回避している。自動メモリ管理のガーベジコレクタの導入も特徴であり堅牢性が重視されている。なお、ジェネリックプログラミングも採用されており利便性も図られている。

Self 1987年

メッセージ構文重視のオブジェクト指向言語。動的型付けを重視した言語であり、予め用意されたオブジェクトを複製して任意の拡張を施すプロトタイプベースの仕組みを初めて実装した。Smalltalkと同様に専用のランタイム環境で実行されたが、これも実用面では初となる実行時コンパイラ（just-in-time compiler）の機能が備えられて速度面でも画期的なものとなった。

CLOS 1988年

Common Lispにクラスベースのオブジェクト指向を追加したもの。

Python 1994年

プロトタイプベースとクラスベースの双方を兼ねたオブジェクト指向スクリプト言語。インタプリタ式で動作する。動的型付けを重視している。従来の型宣言制約を緩めた動的バインディングの柔軟性が扱いやすく奥の深いオブジェクト指向プログラミングを実現している。言語仕様が比較的簡素化され、ガーベジコレクションも実装されており高い堅牢性を持つ。リフレクションに相当するクラスと関数のメタデータ・カスタマイズは利便性に加えて保守性をも向上させた。後のオブジェクト指向スクリプト言語の手本になり、2019年現在ではJavaを凌ぐ人気を博すようになった。

Java 1995年

C++をモデルにしつつ堅牢性とセキュリティを重視したクラスベースのオブジェクト指向言語。その二つの理念を実現するために、静的型付けの重視、仮想マシン上の実行、ガーベジコレクション、サンドボックスモデル、例外処理などを採用し、ポインタ、多重継承、ジェネリックプログラミング、演算子オーバーロードなどを破棄した。アップデートに伴いリフレクション、分散オブジェクト、コレクション用ジェネリクス、並行処理、関数型プログラミングなど様々なパラダイムも追加されている。非常に整えられたハイブリッド言語である。

Delphi 1995年

Object Pascalを発展させたもので、データベースの操作プログラム開発などを主な用途とした。一時期Javaの対抗馬になった。

Ruby 1995年

Pythonを意識して開発されたオブジェクト指向スクリプト言語。日本で誕生してグローバル化したプログラミング言語である。動的型付けを重視している。ミックスインの採用が特徴である。

JavaScript 1996年

WEBアプリケーション開発を主な目的にしていたオブジェクト指向スクリプト言語。Smalltalkの思想を受け継いでデザインされたプロトタイプベースの導入は、オブジェクトのカスタマイズを明快かつ有用にして画期的なプログラミング環境を実現した。同様の思想に基づいて動的型付けを本命にし静的型付けが放棄されている。様々に応用可能な動的バインディング機能は平易で柔軟なデザインパターンを促進している。2019年現在ではPython、Javaと並んでOOP御三家に位置付けられている。ECMAScriptとして標準化されている。ECMAScript 2015ではクラスベース向けの構文もサポートするようになった。

C# 2000年

Javaを強く意識してマイクロソフト社が開発したクラスベースのオブジェクト指向言語。.NET Frameworkなどの共通言語基盤上で実行される。言語仕様面で数々の野心的な拡張が施されており、高度なコーディングスタイルを実現している。静的型付けを重視しつつ動的型付けの比重も高めて4.0から漸進的型付けが採用された。こちらもよく整えられたマルチパラダイム言語として知られる。

Scala 2003年

クラスベースのオブジェクト指向と関数型プログラミングを連携させた言語。オブジェクトは関数の引数または返値として扱われる対象データ存在になるだけでなく、オブジェクトにもラムダ計算的解釈が適用できるので主体的な評価式存在にもなれる。関数、オブジェクト、オブジェクトメソッドの三者にそれぞれ高階関数、第一級関数、評価式の役割を自在に演じさせてモナド的な関数連鎖を織りなす柔軟なプログラミングが可能である。結果的に関数型と抽象データ型の親和性を世に証明する言語になった。

Kotlin 2011年

Javaバイトコードを出力し、Java仮想マシン上で動作するJavaテクノロジー互換言語である。グローバル関数、グローバル変数の使用も容認されており、オブジェクト指向プログラミングを手続き型プログラミングのスタイルに崩したかのようにデザインされている。

TypeScript 2012年

JavaScriptを強く意識してマイクロソフト社が開発したオブジェクト指向スクリプト言語。Typeの名は、静的型付けを再び取り上げて動的型付けと合わせて活用するための漸進的型付けの提唱に因んでいるようである。

Swift 2014年

最新スタイルのマルチパラダイムプログラミング言語。オブジェクト指向はクラスベースで静的型付け重視である。

用語と解説

クラス

詳細は「クラス (コンピュータ)」を参照

クラスベース

詳細は「クラスベース」を参照

クラス (class) は大多数のオブジェクト指向プログラミング言語で提供されている仕組みであり、上記の機能のほとんど全てに関わりがある。概念的にはクラスはオブジェクトの種類を表す。このためオブジェクトはクラスに属するという言い方をする。あるクラスに属するオブジェクトのことをそのクラスのインスタンス (instance) と呼ぶ。データ型の理論から見た場合クラスは型を定義する手段の一つである。クラスによってオブジェクトを記述する言語をクラスベース (class-based) のオブジェクト指向プログラミング言語と呼ぶ。

ハイブリッド型オブジェクト指向プログラミング言語では在来のレコード型（Cでは構造体）の構文を拡張してクラスの定義を行うようにしたものが多い。

多くのオブジェクト指向プログラミング言語ではクラスをデータメンバとメソッドの集まりとして記述する。平たく言えばデータ・メンバの集まりはオブジェクトが保持するデータの形式を定め、各メソッドはそれぞれオブジェクトが処理する特定のメッセージの処理方法を定める。しばしばデータ・メンバとメソッドには個別にアクセス権が設定できるようになっていて、そのクラスに属するオブジェクトが内部的に利用するものと他のクラスに属するオブジェクトに公開するものを分類できるようになっている。多くの場合、公開されたメソッドの集まりは全体として処理可能なメッセージのカタログの機能、即ちインタフェースを提供する。各言語によって異なるが特定の名前のメソッドを定めて、オブジェクトの生成や初期化時の処理、廃棄時の処理などを記述できるようにすることも多い。

多くの言語でクラスは言語の要素として直接実現されているが、これは実行効率のためであり、そのように実現することが必須というわけではない。実際、各クラスをそれぞれオブジェクトとして提供する言語も存在する（例：Smalltalk）。このような言語ではある種のリフレクション (reflection) が可能となる。即ち必要があればプログラムで実行時にクラスの動作を変更することが可能である。これは非常に大きな柔軟性を提供するが、言語処理系による最適化が難しいため実行効率は低下することが多い。近年では柔軟性と効率性を両立させるために基本的に言語要素としてクラスを提供した上で、リフレクション機能が必要なプログラムに対しては必要に応じて各クラスに対応するクラス・オブジェクトをプログラムが獲得できるようにしている言語が現れてきている。（例：JavaのリフレクションAPI）

プロトタイプベース

詳細は「プロトタイプベース」を参照

クラスは非常に多くのオブジェクト指向プログラミング言語で提供されている機能ではあるが、オブジェクト指向プログラミング言語に必須の機能というわけではない。実際にオブジェクトの管理や、データ・メンバやメソッドの記述、継承に際してクラスという仕組みに依存せずに、もしくはクラスという仕組み自体を持たずに別の手段でこれらを実現している言語も存在する。このような言語をインスタンスベース (instance-based)、オブジェクトベース (object-based) あるいはプロトタイプベース (prototype-based) のオブジェクト指向プログラミング言語と呼ぶ。インスタンスベースまたはそれに類するオブジェクト指向プログラミング言語には以下のようなものがある：

• Self
• JavaScript
• NewtonScript
• ドリトル
• Squeak eToys（Squeakの非開発者向けビジュアルスクリプト言語。SqueakToys とも）

なお、クラスベースの言語とインスタンス・ベースの言語との間には明確な境界線はない。たとえば、インスタンス・ベースの代表格ともいえる Self には、traits と呼ばれるクラスのような仕組みが追加されているし、JavaScript、NewtonScript に至っては traits 類似の仕組みを「クラス」と呼称している。また逆に、クラスベースの言語でもクローンを行うメソッドを備え、委譲の仕組みを記述すればある程度はインスタンス・ベースのスタイルでプログラムを記述できる。

インスタンス・ベースの言語ではオブジェクトの生成は既存のオブジェクト、特にプロトタイプ（prototype、原型）と呼ばれるオブジェクトからのクローンによって行われる。当然、一群のクローンはその親、ひいてはプロトタイプと同一の種類のオブジェクトと見なされる。メソッドはプロトタイプ・オブジェクトに属し、メッセージは委譲によってそのオブジェクトが覚えているコピー元へ向かってプロトタイプまで順にメッセージが中継されてから処理される。新しい種類のオブジェクトが必要な場合は適当なオブジェクトをクローンした後で必要なデータ・メンバやメソッドを追加あるいは削除し新たなプロトタイプとすることで行われる。追加されたのでないメソッドに対応するメッセージについてはコピー元のオブジェクトに処理を委譲する。

クラスベースの言語との関係について考えてみると、クローンはプロトタイプと同一の「クラス」に属すると見なし、データ・メンバやメソッドが追加・削除されてあらたなプロトタイプが作られると別の「クラス」が内部的に生成されると考えることができる。ここでデータ・メンバやメソッドの追加のみを許して削除を許さないよう制限すればクローンの「クラス」がその親の「クラス」を継承した場合と同等になる。このためメッセージが委譲の連鎖をたどって配送されるという効率上の問題を無視すれば理論上、インスタンス・ベースの言語の記述能力はクラス・ベースの言語を包含していると言える。ただ、インスタンス・ベースの言語でも実行効率上の問題からなんらかのクラスに似た仕組みを備えている場合が多い。

データメンバ

データメンバ (data member) は、他のオブジェクトに対する参照やポインタであるか、他のオブジェクトそのものである。参照かポインタである場合にはそのデータメンバの参照するのはデータメンバが記述されているクラスそのもののインスタンスに対する参照であっても良い。

一般にデータメンバはインスタンスデータメンバ（インスタンスフィールド）とクラスデータメンバ（静的変数）の2種類に大別できる。効率上の観点から言語が提供する基本オブジェクトの定数を表すデータメンバは特別扱いされる。そのような定数を表すデータメンバを特に定数データメンバ (constant data member) と呼ぶ。データメンバはC++などの言語ではメンバ変数 (member variable)、Javaなどではフィールドと呼ばれることがあり、UMLでは属性と呼ばれる。

インスタンスデータメンバ

詳細は「インスタンス変数」を参照

インスタンスデータメンバ（一般に単にデータメンバと言われる場合はこちら）はそのクラスのインスタンス各々に保持される。インスタンスデータメンバの集まりはそのクラスのインスタンスが保持するデータの形式を定める。インスタンスデータメンバは単にデータメンバと呼ばれることも多い。

Smalltalkではインスタンス変数 (instance variable) と呼ばれる。

クラスデータメンバ

詳細は「クラス変数」を参照

クラスデータメンバはそのクラスオブジェクトとインスタンスオブジェクトの間で共有されるデータである。

Smalltalkではクラスデータメンバはクラス変数 (class variable) と呼ばれる。また、C++・Javaでは歴史的事情によりクラスデータメンバは静的データメンバ (static data member)、静的変数 (static variable)、静的フィールド (static field) と呼ばれる。ただし、Smalltalkのクラス変数はC++やJavaのクラス変数とは異なる。Smalltalkにおいて、C++やJavaのクラス変数と同等となる変数はプール辞書 (pool dictionary) と呼ばれる。

メソッド

メソッド (method) は特定の種類のメッセージの処理方法を記述したものである。メソッドもインスタンス・メソッドとクラス・メソッドの2種にできる。インスタンス・メソッドはそのクラスの各インスタンスオブジェクトを操作し、クラス・メソッドはクラスオブジェクトを操作する。メソッドとの集まりはそのクラスのオブジェクトが処理可能なメッセージのカタログの機能を果たす。

一例として、C++では、メソッドはメンバ関数 (member function) や関数メンバ (function member) と呼ばれる。これはC++がグローバル関数との区別をつけることと、クラスを抽象データ型の拡張と位置づけ、非メッセージメタファな言語思想を持っているためである。これら言語ではメソッドをオブジェクト（=クラスやインスタンス）の持ち物として捉えず、クラスに定義された機能要素であると考える。メッセージメタファを否定するため、同時にメッセージを実行するメソッド（手法）ではありえない。

クラスメソッド

クラス・メソッドだが、オブジェクト指向の本義に立ち返れば、クラス・メソッドがあるということはクラスがメッセージをレシーブできるという事になる。クラスがメソッドを持つことは便利だが、クラスをオブジェクトとすると実行効率に劣るため、双方の利点を享受できるこのような折中的仕様を取る言語は多い。

C++ではクラスはオブジェクトでは無いが、一方でクラスに属するメソッドは存在する。Eiffelではクラスはオブジェクトでは無いためクラスのメソッドであるクラス・メソッドは存在しない。Smalltalkではクラスもオブジェクトの一種であるため当然クラスはメソッドをもつ。

クラス・メソッドは、C++では静的メンバ関数 (static member function) と呼ばれる。これはクラスがオブジェクトでない言語にとってはクラス・メソッドより正確な表現であり適切である。（"static" とはCのstatic変数に由来しauto変数の対語である。関数コールによりスタック上に生成される関数インスタンスに依存しない変数と、インスタンス生成有無にかかわらず実行できる関数の類似による。）Javaではクラス・メソッドは静的メソッド (static method) とも呼ばれることもある。

コンストラクタとデストラクタ

初期化に利用されるメソッドをコンストラクタあるいは構築子 (constructor)、廃棄時に利用されるメソッドをデストラクタと呼んで特別に扱うことが多い。コンストラクタが初期化だけを担う場合はイニシャライザあるいは初期化子 (initializer) と呼ばれることもある。Javaはオブジェクトの寿命管理にガベージコレクションを用いるため、デストラクタをサポートしない。ただし、オブジェクトがガベージコレクションによって破棄されるときに呼び出されるファイナライザ (finalizer) をサポートし、Object#finalize()メソッドがその役割を果たす。ただし、ファイナライザはC++のデストラクタと違ってユーザーコードで明示的に呼び出すことはできない。ファイナライザが呼び出されるタイミングをプログラマが制御することはできず、最終防壁（フェイルセーフ）としての役割しか持たないため、Javaにおけるファイナライザは本当に必要でない限り使用するべきではない。C#もファイナライザをサポートする（構文はC++のデストラクタに似ており、かつてはデストラクタと呼ばれていたが、役割はJavaのファイナライザと同じである）。

データ型の理論においては保持されるデータが必ずその型で認められる正しい値の範囲に収まることを保証するため、生成されるオブジェクトのデータ・メンバが必ず適切なコンストラクタによって初期化されるように求める。またオブジェクトが入出力機器やファイルや通信、プロセスやスレッド、ウィンドウとウィジェットなどハードウェアやオペレーティングシステム (OS) が提供する資源を管理するために利用される場合に、コンストラクタやデストラクタでそれらの資源の使用開始（オープン処理）や使用終了（クローズ処理）をそれぞれ管理し、通常のメソッドでそれらにまつわる各種サービスを提供するようにすることで、それらのリソースがあたかもプログラム中のオブジェクトであるかのように自然に取り扱うことができるようになる（RAII）。

C++やJavaなどでは、コンストラクタはクラスと同じ名前を持ち、戻り値を持たないメソッドとして定義される。C++では一部のコンストラクタは型変換演算子として、また暗黙の型変換にも利用される。

メタクラス

動的型付けを採用するオブジェクト指向言語の多くは、クラスより生成するインスタンスの他にメタクラスという機能を持ちクラス自体をオブジェクトとして扱うことが出来る。このためオブジェクトには、インスタンスオブジェクトとクラスオブジェクトという2種類のオブジェクトが存在する。Java等クラスオブジェクトを持たない言語の文化圏では、インスタンスオブジェクトとオブジェクトを混同して説明される事があるが、Objective-CやPython、Ruby等、インスタンスオブジェクトとクラスオブジェクトが別であるオブジェクト指向言語では区別して説明される。 元々はSmalltalkから始まった用語である。

thisインスタンス

「this (プログラミング)」も参照

そしてあるオブジェクトOにメッセージを配送し適切なメッセージ処理コード（振る舞い）を呼び出す際には、まず対象となるオブジェクトOについて共通部分の格納場所を見つけて適切なコードを選び出し、次にそのコードに対して処理対象となるオブジェクトO固有のデータの所在を示すオブジェクトIDを渡すようになっている。

各オブジェクトの固有データを識別するオブジェクトIDを表現する方法も様々で、オブジェクトのIDとしては名前、番号なども用いられることがあるが、オブジェクトの固有データを記憶している主記憶上のアドレスがそのまま用いられることもある。アドレスを直接利用することは非常に実行効率の向上に寄与するが、プログラム間でのオブジェクトの受け渡し、セッション間（プログラムが終了して再度起動された時など）でのオブジェクトの受け渡しにはそのまま利用することができない。また各オブジェクトの固有データから共通部分の格納場所を見つける方法もまた各言語により異なり、その言語の開発目的に応じて実に多種多様である。

アクセスコントロール

オブジェクト指向プログラミングにおいて、オブジェクトは、カプセル化されておりブラックボックスである。したがって、処理するメッセージのカタログ、つまりインタフェースだけが利用者に公開され、内部の詳細は隠されるのが基本である。しかし、あるクラスのインスタンスの内部だけで利用されるメソッドまで公開してしまうと、利用者にとって煩雑である。また、定数データ・メンバのようなものは一々メソッドでアクセスするようにせず公開してしまっても、カプセル化の利点は失われず効率的でもある。そこで、オブジェクトを定義するプログラマが各データ・メンバやメソッドについて公開・非公開を設定できる機能を用意している言語は多い。

例えば、Javaでは、データ・メンバやメソッドの宣言にpublicと指定すれば、他オブジェクトから自由に利用でき（公開と呼ばれる）、privateと指定すればオブジェクト内だけで利用できるようになる（非公開と呼ばれる）。しかし、ある機能を提供するのに、一個ではなく一群のクラスに属するオブジェクトでそれを記述するのが相応しい事例がある。そのような場合、関係する一群のオブジェクト間でだけデータ・メンバやメソッドを利用できれば便利である。それを可能にするための拡張がいくつか存在する。例えば、継承を利用しているときに、あるクラスが子孫にだけ利用を許可したいデータ・メンバやメソッドがある場合、Javaではprotectedを指定することでそれを実現できる（限定公開と呼ばれる）。また、ある一群の機能を実現するクラスのライブラリで、その実現に関連するクラスに属するオブジェクトだけがデータ・メンバやメソッド利用できるようにしたい場合も考えられる。また、Javaでは、ライブラリを構成するクラス群を表現するパッケージ (package) という仕組みがあり、特に指定がない場合は同一パッケージに属するクラスのオブジェクト間でのみデータ・メンバやメソッドを相互に利用可能である。その他にも、デザインパターンの一つであるFacade パターンでは、この仕組みがテクニックとして応用されている。また、C++ではフレンド宣言という仕組みがあり、あるクラスで外部非公開に指定されているデータ・メンバやメソッドについて、その利用を許可するクラスや関数のリストをクラス内に列挙することができる。なお、public、private、protectedというキーワードは、多くのプログラミング言語で用いられているが、その示す意味は言語ごとに差異があるため、注意が必要である。

メッセージ

「メッセージ転送」も参照

メッセージ (message) はオブジェクト間の通信でやりとりされる情報である。メッセージはメッセージ種別を示すIDとメッセージの種別に応じた追加の情報からなる定まった形式を持つ。追加の情報はそれ自身が何らかのオブジェクトやオブジェクトのIDである場合もある。メッセージの配送には大別して2つの方式がある

• 同期式 - オブジェクトがメッセージの送信を依頼すると相手が受信、処理して結果を返すまでそのオブジェクトは処理を中断して待つ。
• 非同期式 - オブジェクトがメッセージの送信を依頼した後、相手の応答を待たずにオブジェクトは処理を続行する。処理結果は別のメッセージとして返される。

両者とも一長一短がありどちらがすぐれているとは言えない。また並列・並行処理が可能な環境では一方の仕組みがあれば、それを利用してもう一方も実現可能である。一般的な傾向としては、メッセージの伝送や処理に時間が掛かる場合は非同期式の方が効率は良く、そうでない場合には同期式の方が挙動が分かりやすく利用しやすい。並列処理・並行処理システムを記述する言語や分散システムを記述する言語ではOSなどが提供するメッセージ機能や自前の配送メカニズムを使って非同期式でメッセージが配送される場合もあるが、一般にオブジェクト指向プログラミング言語ではその多くが同一のプログラム内の通信であるので同期式のメッセージ配送が利用される。特にコンパイルされるタイプのオブジェクト指向プログラミング言語では、しばしば特別なメッセージ配送の仕組みを用意せず、特別な形式の関数の呼び出しでメッセージの配送を直接に表現する。即ち、各メソッドを内部的には関数として実現し、メッセージIDはメソッド名で表し、関数の第一引数としてオブジェクトIDを渡し（この第一引数は多くの言語で特別な記法で表される）、追加の引数としてメッセージの追加部分の情報を渡すのである。こうするとメッセージ送信は直接的なメソッドの関数呼び出しとして表せる。ただし、プログラムで継承の仕組みが利用されている場合はプログラムのテキストからだけでは呼び出すべきメソッドが決定できない場合があるので、実行時にメソッドを決定するためにメソッド・サーチや仮想関数テーブルといった仕組みが必要となる。多くのプログラミング言語においてメッセージは、メソッド呼び出しの比喩でしかないことが多い。SmalltalkやObjective-Cの様な言語では、メッセージはメソッド呼び出しとは独立した機構として存在している。メッセージが機構として存在する言語では、メッセージをオブジェクトに送信した際、宛先のオブジェクトにメッセージで指定したメソッドが存在しない場合でもメッセージを処理することが出来る。これを利用し、メッセージの配送先を別のオブジェクトに指定したり、メッセージを一時保存したり、不要なメッセージを無視する等といったメッセージ処理が行われる。

関連項目

• メッセージ (コンピュータ)
• メソッド (計算機科学)
• フィールド (計算機科学)
• インスタンス変数
• クラス変数
• クラス (コンピュータ)
• インスタンス
• カプセル化
• 継承
• 委譲
• プログラミング言語
• オブジェクト指向モデリング
• オブジェクト指向分析設計
• オブジェクト指向
• オブジェクトデータベース
• トップダウン設計とボトムアップ設計
• オブジェクト関係マッピング