編集(オブジェクト指向言語から転送)この記事には複数の問題があります。改善やノートページでの議論にご協力ください。出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。(2019年2月)独自研究が含まれているおそれがあります。(2018年2月)正確性に疑問が呈されています。programming、略語:OOP)は、オブジェクト指向の考え方に基づいたコンピュータプログラミング手法である。オブジェクトとは大まかに言うとデータ(変数またはプロパティ)とコード(関数またはメソッド)の複合体を意味しているが、その詳細については様々な解釈が存在する。OOPに基づくプログラムはこのオブジェクトの集合として組み立てられる事になるが、その実装スタイルもまた千差万別である。オブジェクト指向プログラミングという言葉自体は計算機科学者アラン・ケイが作り出したものである。彼は1967年に公開されたSimula67のクラスとオブジェクトを備えた言語設計を見た際にobject-orientedという造語を咄嗟に口にしたとされ、その造語はケイ自身が1972年から80年にかけて開発したSmalltalkの言語設計を説明する中で初めて用いられて世間に知られるようになった。Smalltalkが示したあらゆるプログラム内要素をオブジェクトとして扱いメッセージパッシングでコミュニケーションさせるという元祖オブジェクト指向の考え方は、様々な理由から広くは認知されず、オブジェクトというプログラム概念を強く認識させるのみに留まった。同時にここからOOP定義の一人歩きが始まり様々な解釈が生まれる事になる。した中で1983年に公開されたC++の言語設計がひときわ注目を集めた事が契機となり、OOPに対する考え方が大きく再定義された。C++はSimula67の方を参考にしていた。最終的にこのC++の設計スタイルがOOPの主流となるに到り、同時にOOPの三原則とされるカプセル化、継承、多態性のプログラミングパラダイムが確立されている。principle)または三本の柱(pillar)が存在し、それに従った言語仕様を総体的または部分的に備えたプログラミング言語がオブジェクト指向準拠と判別される。1~3は、オブジェクト指向プログラミングの三原則または三本柱とされるものでありC++を契機にして提唱された。polymorphism)の一つ。5と6は、Smalltalk開発者が重視する元祖オブジェクト指向のコンセプトである。任意のデータ(変数、プロパティ)と、それに関連するコード(関数、プロシージャ)をひとまとめにしてオブジェクトとし、外部に対して必要とされるデータとコードのみを公開する仕組みがカプセル化と呼ばれる。オブジェクトが持つコードは一般に「メソッド」と呼ばれる事が多い。オブジェクトの設計はデータ構成を中心にして、それに関連したメソッドを定義するのが基本になる。外部公開されないデータとメソッドは隠蔽される事になり、これは情報隠蔽または内部隠蔽と呼ばれる。公開されたデータは、該当オブジェクトの外部にあるメソッドから直接参照(読み込み)ないし変更(書き込み)する事できる。公開されたメソッドは同様に該当オブジェクトの外部にあるメソッドから直接呼び出す事ができる。隠蔽されたデータとメソッドは外部からアクセスできない。任意の既存オブジェクトのデータ構成とメソッド構成を引き継いで、新しいオブジェクトを定義する仕組みが継承と呼ばれる。引き継ぐ際には新たなデータとメソッドを自由に追加できるので、新生オブジェクトの構成は既存+追加内容になる。結果的に既存オブジェクトの内容を使い回せる事にもなるのでソースコードの再利用性を高めると見なされた。オブジェクトはソースコード上ではクラスとして定義されるので、継承元の親クラスはスーパークラス、継承先の子クラスはサブクラスと呼ばれる。クラスは自身のスーパークラスを複数個指定する事もできる。polymorphism)サブタイプ多態性(subtyping)の三分類からなるパラダイムであるが、前二者は事実上コンパイル時に状態が決定される静的なものなのでここでは割愛し、実行時に状態が決定される動的なサブタイプ多態性のみを扱う。サブタイプ多態性の代表例である仮想関数は、上述の継承におけるスーパークラスとサブクラスの繋がりを利用した仕組みであり、一つのスーパークラス抽象メソッドの呼び出しから、その実行時に対応した様々なサブクラス実装メソッドに多方向分岐するプロセスを指す。オブジェクト指向のスタイルでは、それぞれ実装が異なる抽象オブジェクトの集合をリストにまとめて順繰りに処理する手法が好まれるので、この仮想関数と多態性はほとんど同義に説明される事が多い。動的ディスパッチは、主に分散コンピューティングを表現するオブジェクト間通信で用いられる技法であり、その実装の仕方は様々でやや曖昧な仕様でもある。呼び出されたローカルメソッドまたはリモートメソッドがオブジェクト内部の実行時状態に準じた多相な処理を行ってその結果を返す、といったランタイム環境上のプロセスが動的ディスパッチのカテゴリで括られている。多重ディスパッチは動的な関数オーバーロードに相当する。casting)された後に、その引数パターンに対応した同名関数または分岐ルーチンに処理が移行されるという実行時変化プロセスを指した。ダブルディスパッチは多重ディスパッチの亜流であり、二通りの考え方がある。動的型審査および型変化されるBオブジェクトを単一引数にしてAオブジェクトの仮想関数メソッドを呼び出す形態と、多重ディスパッチに用いる引数を二つに限定した形態である。いずれも実行時状態に応じた動的変化プロセスになった。これは主にデータ集合を連続的または再帰的に処理するアルゴリズムで用いられる。クラス的抽象、振る舞い的抽象、オブジェクト的抽象の六つのタイプがある。プロパティ的抽象の実例はゲッターである。指定変数の直接リターンではなく、リクエスト時の環境に合わせて元の変数値を再解釈する一定の仲介コードを通した上でリターンするものを指す。メソッド的抽象の実例は仮想関数である。基底クラスで仮想関数として定義されたメソッドが、その派生クラス内の同名メソッドの抽象点になる。型的抽象の実例は型システムと型推論になる。型のメタデータを定義する事で、その型の性質および用いられ方によるアスペクトを事前の抽象点にし、型推論によってコード上のそれぞれの型が内包する抽象点を照合して等価な計算を可能にする。クラス的抽象の実例は、一定の目的に従ってデータメンバとメソッドを適切に隠蔽したクラスのカプセル化を指す。これは抽象化の語意通りに、クラスから関心対象のみを抜き出して他は省くデザインにつながる。振る舞い的抽象の実例はインターフェースである。インターフェースはほとんどの場合、抽象メソッドの集合体として形成され、その関連クラスに共通した動作アスペクトを表現する。この動作アスペクトはプログラム全体から各オブジェクトが持つ特定プロセスの抽象点として利用される。オブジェクト的抽象の実例はソフトウェアコンポーネント、オブジェクト間通信、プロトコル(英語版)などを指す。ここでも一般にインターフェースの仕組みが用いられる。このインターフェースは一つから複数個の実体オブジェクトを取り扱って、リクエストに応じたプロセスの実行またはデータの提供を実現する。リクエスト側と対象オブジェクトの仲介役であり、リクエスト側から見ると特定のオブジェクトまたは漠然としたオブジェクトの存在を、その時の利用目的に絞って抽象化したものになる。メッセージング編集メッセージングは哲学的側面が強いパラダイムである。仕組み的には、オブジェクト(=インスタンス)のメソッドコール、またはオブジェクト間通信におけるリモートメソッドコールと同じものと考えてよいが、メッセージングのパラダイム下では、イメージ的にオブジェクトそのものをメソッドとしてコールする点が異なっている。それは各オブジェクトが一般にレシーバーと呼ばれるデフォルトメソッドを持つ事で実現されている。オブジェクトのコールとは、このレシーバーをコールするのと同義となる。引数無しでコールされる事はなく基本的に一つのオブジェクトが引数となってコールされる。これも留意すべき点である。元祖オブジェクト指向では「EverythingIsAnObject」の通り、プリミティブからデータストラクチャ、コードブロックまであらゆるプログラム要素がオブジェクトとされる。これは「Bを引数にしてAを呼び出す」の意味であり、イメージ的に「Aに対してBというメッセージを送る」と形容される。引数Bを受け取ったAのレシーバー内で任意の処理が行われた後に結果値としてのオブジェクトが返される。Aそのものが返される事もあれば、別のオブジェクトが返される事もある。この流れがメッセージングと呼ばれるものである。返値オブジェクトに対して別のメッセージを送る事も可能であり、また返値オブジェクトをメッセージにして別のオブジェクトに送る事も出来る。したメッセージングの連鎖はAのレシーバー内でも同様に行なわれる。メッセージング・パラダイム下でのオブジェクトは言わば独自の記憶を備えた変換式であり、これらオブジェクトのコミュニケーションとは高階関数と第一級関数の仕組みと同じものである。メッセージング・パラダイムの本質はオブジェクトの代数(algebra)化であり、その代数値は前述のメッセージングの連鎖による結果値である。メッセージングを行なうオブジェクトもまたメッセージング連鎖の集合体という事になる。それはただのプリミティブ値であっても決して例外ではない。レシーバーでの処理をコードとすると、メッセージング・パラダイム下でのデータはメッセージング連鎖によるコードの集合体であり、その各コードは他のデータ群を参照しており、その各データもまたコードの集合体~という風になる。最終的には根っことなるオブジェクトの定形データに行き着いてそれが値算出の原点になるが、こうなるとイメージ的にコードとデータが融合して両者の区別はなくなる。オブジェクトは抽象化の一形態である代数的(algebraic)存在なので、代数計算と同様に理念的には単体で成り立つ事はなく、オブジェクト自体もその様にデザインされる事が原則的に求められている。二つ以上のオブジェクトが出会うメッセージングによって始めて一つのデータが正式に体現される事になり、同時に一つのプロセスが発生する。これが引数無しでもよいメソッドと引数が要るメッセージングの明確な違いである。実装面では便宜上の理由から、メッセージングの際の引数オブジェクトにはセレクタを付けるのが許容されている。selector:B」の様になる。セレクタはメソッド名と同義であり、引数オブジェクトに貼られるラベルと考えていいものである。セレクタによってレシーバー外の対応メソッドに自動分岐されるのでコーディングが簡便になる。演算子も事実上のセレクタであり「5+3」は、+セレクタを貼った3オブジェクトを5に送ると解釈できる。括弧記号はコンパイラのためのただのディレクティブとなる。メッセージングは二つのオブジェクトが出会った時点で発生するプロセスなので引数は常に一つであり、複数の引数を用いたい場合はパーシャルアプリケーションまたはカリー化を適用するべきであるが、これは困難なコーディングになる事が多いので、セレクタによるパターンマッチング的な各メソッドへの自動分岐も許容されている。このメッセージングのパラダイムは様々な理由から広くは認知されず、やがてその言葉だけが一人歩きするようになって本来の定義からシフトし、前述のレシーバーの仕組み自体がメッセージングと見なされるようにもなり、オブジェクト間通信で行なわれるバイトデータ列の送受信もメッセージングの代表例とされるようになった。インスタンスの単純なメソッド呼び出しもメッセージングであると説明される事もある。この様にメッセージングの本質は見失われながらも、その側面的仕様は数々のOOP言語に導入されてもいる。遅延バインディング編集この節の加筆が望まれています。歴史編集オブジェクト指向プログラミングという考え方が生まれた背景には、計算機の性能向上によって従来より大規模なソフトウェアが書かれるようになってきたということが挙げられる。crisis)」といったようなことも危惧されるようになってきた。誕生)などが行われるようになった。それに続けて「しかしデータについては相変わらず主記憶上の記憶場所に置かれている限られた種類の基本データ型の値という比較的低レベルの抽象化から抜け出せなかった。これはコードはそれ自身で意味的なまとまりを持つがデータはそれを処理するコードと組み合わせないと十分に意味が表現できないという性質があるためであった。」といったように、ほぼ間違いなく説明されている。定義とプログラム内の実体が一対一に対応する手続きや関数とは異なり、データはその形式の定義に対して値となる実体(インスタンスと呼ばれる)が複数存在し、各々様々な寿命を持つのが通例であるため、そのような複数の実体をうまく管理する枠組みも必要であることがわかってきた。Simulaのオブジェクトとクラスというアイデアは異なる二つの概念に継承される。一つはシステム全てをオブジェクトの集合と捉え、オブジェクトの相互作用をメッセージに喩えた「オブジェクト指向」である。オブジェクト間の相互作用をメッセージの送受と捉えることで、オブジェクトは受信したメッセージに見合った手続き単位(≒関数)を自身で起動すると考える。結果オブジェクトは自身の持つ手続きのカプセル化を行うことができ、メッセージが同じでもレシーバオブジェクトによって行われる手続きは異なる――多相性(ポリモーフィズム)を実現した(このメッセージを受け実行される手続き単位は、メッセージで依頼されたことを行うための「手法」の意味でメソッドと呼ばれる)。この思想に基づき作られたのがSmalltalk(1972年)であり、オブジェクト指向という言葉はこのときアラン・ケイによって作られた。コンパイラ設計上の制約により、変数メタファである動的束縛の特徴は除外された)。呼ばれ、オブジェクトのメンバ関数を実体ではなくポインタとすることで、継承関係にあるクラスのメンバ関数のオーバーライド(上書き)を可能にしたことで、多相性を実現した(この流儀ではメッセージメタファはオブジェクト指向に必須ではないものと定義し、オブジェクトの持つ手続きをメソッドとは呼ばずメンバ関数と呼ぶ)。この他、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年代後半からオブジェクト指向は広く普及するようになった。OOP言語一覧編集OOP言語の系譜オブジェクト指向を総体的または部分的にサポートする機能を備えたプログラミング言語の公開は、1980年代後半から顕著となった。OOP言語の分類法は複数あるが、Smalltalkをルーツとするメッセージパッシングの構文が重視されてるか否かで大別される事が多い。ないものがOOP言語の主流となっており「C++」「Java」「C#」「Swift」などがその代表とされる。メッセージパッシングを重視するOOP言語には「Smalltalk」「Objective-C」「Self」などがある。言語仕様の中でオブジェクト指向の存在感が比較的高い代表的なプログラミング言語を以下に列挙する。1967年1962年に公開されたSimulaの後継版であり、クラスのプログラミング概念を導入した最初の言語である。現実世界の擬似モデルを観測するシミュレーション・プログラム制作用に開発されたもので、クラスを実メモリに展開したオブジェクトは、その観測対象要素となった。Simulaのクラスは、サブルーチンに専用変数と補助プロシージャを加えた機能的小型モジュールに近いものであったが、継承と仮想関数という先進的な設計を備えていた事でOOPの草分けと見なされるようになった。C++、Java、C#の設計母体となった。変数、構造体、コードブロック、メタデータまでのあらゆる要素をオブジェクトとする概念を編み出した最初の言語でもある。オブジェクト指向という言葉は、Smalltalk開発者がその言語設計を説明する中で生み出された。オブジェクトの基礎的な振る舞いを規定する限られた予約語の他は、オブジェクトとメッセージのやり取りで制御構造を含めたあらゆるプロセスを表現出来た。専用のランタイム環境上でプログラムを実行する設計を応用して動的な多態性とセキュリティに繋がるモニタリングも実現した。これは後に仮想マシンと呼ばれるものとなり、JavaやC#に踏襲された。1983年C言語にOOPデザインを追加したもの。Simulaの影響を受けている。クラスのメカニズムが備えられて、カプセル化、継承、多態性といったOOP仕様を実装している。テンプレート機能や例外処理、演算子オーバーロードを応用した関数オブジェクトなど様々なプログラミングパラダイムも導入された。元がC言語であるため、OOPから逸脱したコーディングも多用できる点が物議を醸したが、その是非はプログラマ次第であるという結論に落ち着いた。1984年C言語をOOPデザイン化したもの。こちらはSmalltalkの影響を受けており、それに準じたメッセージパッシングとリフレクションのメカニズムが備えられた。OOP的には前述のC++よりも正統であると見なされた。制御構文が追加され、メッセージの仕様もやや簡素化されるなど実践上の便宜が図られており、Smalltalkよりもコーディングし易くなった。1986年PascalをOOPデザイン化したもの。1986年PascalをベースにしてOOPデザイン化し、またジェネリックプログラミングを追加した。型付けは静的に限られ、非参照データを自動解放するガーベジコレクタを持ち、多重継承時の問題を回避する仕組みや例外処理など高い堅牢性を備えた。これらは後のJavaやC#の手本となった。1987年メッセージパッシングの構文が中心となっている。動的な多態性を重視した言語であり、従来のクラスベースのオブジェクト設計に対して、システム側が用意したオブジェクトを複製して任意の拡張を施すプロトタイプベースのデザインを初めて実装した。compiler)の機能が備えられて速度面でも画期的なものとなった。LispをOOPデザイン化したもの。1990年インタプリタ式で動作する。言語仕様を簡素化し自動メモリ管理機能を実装して扱いやすく理解しやすいOOPを目指している。後のOOPスクリプト言語の手本となった。堅牢性と安全性を重視したOOP言語。その二つの理念を実現するために、仮想マシン上の実行、ガーベジコレクタ、例外処理などを採用し、ポインタと直アドレス変数、多重継承、ジェネリックプログラミング、演算子オーバーロードなどを破棄した。破棄部分についてはその埋め合わせの設計も備えられた。クラスのメカニズムを中心にしたOOPであるが、様々なプログラミングパラダイムも追加されている。非常に整えられたハイブリッドOOP言語である。Pascalを発展させたもので、データベースの操作プログラム開発などを主な用途とした。一時期Javaの対抗馬となった。1995年OOPデザインされたスクリプト言語である。インタプリタ式で動作する。スクリプトでありながら、クラス、マルチスレッド、例外処理、そしてソフトウェアコンポーネント(モジュール)を扱えるMixinといった利便性の高い機能も備えている。1996年ウェブアプリケーション開発を主な目的とするOOPスクリプト言語。プロトタイプベースでオブジェクトを扱う事でコーディングを簡便にしている。ECMAScriptとして標準化されている。2015ではクラス構文をサポートするようになった。2000年Javaを強く意識して開発されたOOP言語。Frameworkなどの共通言語基盤上で実行される。Javaと同等または部分的に拡張させたスタイルを持ち、こちらもよく整えられたハイブリッドOOP言語として知られる。BasicをOOPデザイン化したもの。Frameworkなどの共通言語基盤上で実行される。2011年Javaを元に開発され、その長所と短所を見直しつつ再設計されたOOP言語。Javaの改造版である。JavaScriptにもコンバートできる。2011年Javaバイトコードを出力し、Java仮想マシン上で動作するJavaテクノロジー互換OOP言語である。OOPでありながらグローバル関数および変数の使用も容認されており、オブジェクト指向プログラミングを手続き型プログラミングのスタイルに崩したかのようにデザインされている。高度に整えられたマルチパラダイムプログラミング言語。クラスをベースにしたオブジェクト指向プログラミングも導入されている。OOP言語の仕組み編集オブジェクト指向プログラミング言語は、相互にメッセージを送りあうオブジェクトの集まりとしてプログラムを構成することができる仕組みを持つ。そのために、少なくともオブジェクトについての3つの仕組みと、オブジェクトの管理についての3つの仕組みが必要となる。オブジェクトの仕組みオブジェクトに蓄えられる情報、データを表現する仕組み。他のオブジェクトにメッセージを配送する仕組み。受け入れ可能な各種メッセージに対応して、処理する事柄を記述する仕組み(メソッド)。オブジェクトを管理する仕組みオブジェクト間の関係を整理分類して系統立てる仕組み。必要なオブジェクトを作成・準備する仕組み。不要なオブジェクトを安全に破棄する仕組み。これらをどのように言語の要素として提供し、どのような機械語コードで実現するかによって様々なオブジェクト指向プログラミング言語のバリエーションが生まれる。以下、オブジェクト指向プログラミング言語が提供する様々な要素が上記の仕組みをどのように実現しているかについて概観する。オブジェクト指向プログラミングの中心となる概念であり、この概念を実際にどう実現するかはオブジェクト指向プログラミング言語により異なる。以下、概念と実際がどう対応しているかについて説明する。概念的には各々のオブジェクトは、プログラムが表現する情報システムの中で能動的な役割を持った存在を表現している。メッセージを受け取り、その処理の過程で内部に蓄えたデータを書き換え、必要に応じて他のオブジェクトにメッセージを送るといった動作をしている。コードとデータが一つになっている。実際のプログラムでは、全てのオブジェクトが互いに全く異なった存在ではなくオブジェクトは種類に分けることが出来る。データは異なっても社員は皆、出勤し退勤するという処理(振る舞い)は同じだろう。このように複数の異なるオブジェクトが同じ種類のメッセージを受け取り共通の処理をするのが普通である。このような場合、各オブジェクトがそれぞれメッセージ処理のコード(前述の「振る舞い」に当たる)を独自に備えていては無駄である。そこでオブジェクト指向プログラミング言語がオブジェクトを実現する際には多くの場合、内部的にはオブジェクトを2つの部分に分けている。一つは同一種類のオブジェクトに共有される部分、例えばメッセージ処理のコード(振る舞い)や定数(どのオブジェクトでも異ならないデータ)の類である。同一種類のオブジェクトの間で変わる個々の部分もう一つは同一種類のオブジェクトでもそれぞれ異なる部分、典型的には各オブジェクトが保持するデータ群である。動的型付けを採用するオブジェクト指向言語の多くは、クラスより生成するインスタンスの他にメタクラスという機能を持ちクラス自体をオブジェクトとして扱うことが出来る。このためオブジェクトには、インスタンスオブジェクトとクラスオブジェクトという2種類のオブジェクトが存在する。Java等クラスオブジェクトを持たない言語の文化圏では、インスタンスオブジェクトとオブジェクトを混同して説明される事があるが、Objective-CやPython、Ruby等、インスタンスオブジェクトとクラスオブジェクトが別であるオブジェクト指向言語では区別して説明される。[1][2][3]元々はSmalltalkから始まった用語である。(プログラミング)」も参照そしてあるオブジェクトOにメッセージを配送し適切なメッセージ処理コード(振る舞い)を呼び出す際には、まず対象となるオブジェクトOについて共通部分の格納場所を見つけて適切なコードを選び出し、次にそのコードに対して処理対象となるオブジェクトO固有のデータの所在を示すオブジェクトIDを渡すようになっている。各オブジェクトの固有データを識別するオブジェクトIDを表現する方法も様々で、オブジェクトのIDとしては名前、番号なども用いられることがあるが、オブジェクトの固有データを記憶している主記憶上のアドレスがそのまま用いられることもある。アドレスを直接利用することは非常に実行効率の向上に寄与するが、プログラム間でのオブジェクトの受け渡し、セッション間(プログラムが終了して再度起動された時など)でのオブジェクトの受け渡しにはそのまま利用することができない。各オブジェクトの固有データから共通部分の格納場所を見つける方法もまた各言語により異なり、その言語の開発目的に応じて実に多種多様である。JavaScriptの場合、各オブジェクトは連想配列であり、名前で表現されたメッセージのIDからメッセージ処理コードである関数への参照を直接見つけ出す。各オブジェクトの固有データもその連想配列に格納されていて、メッセージを処理する関数には連想配列のアドレスが渡される。Selfの場合Selfのようなインスタンスベースのオブジェクト指向プログラミング言語では、プロトタイプとなるオブジェクトがメッセージを処理するコードも保持しており、オブジェクトがクローンされて作成されるときにそのプロトタイプのありかを示す情報もコピーされ、メッセージは受け取ったオブジェクトのIDを添えてプロトタイプに送られて処理される(Selfでは実行効率上の問題から後に内部的にクラスを作って利用するようになっている)。普及しているクラスベースの言語では、共通部分はオブジェクトの種類を表現するクラスに保持され、各オブジェクトは固有データと共にそのクラスのIDを保持する。オブジェクトに送られるメッセージはその送り先オブジェクトにあるクラスのIDからクラスを見つけ、その中からメッセージを処理するコードを見つけ出し、処理対象となっているオブジェクトのIDを付してそのコードを呼び出す仕組みになっている。コンポジション編集コンポジションは、複数のオブジェクトがある一つのオブジェクトの構成要素となっている巨大なオブジェクト群をいう。コンポジションのもとにあるオブジェクトは同一の生存期間を持ち、一つの巨大な仮想オブジェクトの構成部品として機能する。オブジェクト間の通信でやりとりされる情報である。メッセージはメッセージ種別を示すIDとメッセージの種別に応じた追加の情報からなる定まった形式を持つ。追加の情報はそれ自身が何らかのオブジェクトやオブジェクトのIDである場合もある。メッセージの配送には大別して2つの方式がある:同期式オブジェクトがメッセージの送信を依頼すると相手が受信、処理して結果を返すまでそのオブジェクトは処理を中断して待つ。非同期式オブジェクトがメッセージの送信を依頼した後、相手の応答を待たずにオブジェクトは処理を続行する。処理結果は別のメッセージとして返される。両者とも一長一短がありどちらがすぐれているとは言えない。並列・並行処理が可能な環境では一方の仕組みがあれば、それを利用してもう一方も実現可能である。システムを記述する言語や分散システムを記述する言語ではOSなどが提供するメッセージ機能や自前の配送メカニズムを使って非同期式でメッセージが配送される場合もあるが、一般にオブジェクト指向プログラミング言語ではその多くが同一のプログラム内の通信であるので同期式のメッセージ配送が利用される。コンパイルされるタイプのオブジェクト指向プログラミング言語では、しばしば特別なメッセージ配送の仕組みを用意せず、特別な形式の関数の呼び出しでメッセージの配送を直接に表現する。各メソッドを内部的には関数として実現し、メッセージIDはメソッド名で表し、関数の第一引数としてオブジェクトIDを渡し(この第一引数は多くの言語で特別な記法で表される)、追加の引数としてメッセージの追加部分の情報を渡すのである。するとメッセージ送信は直接的なメソッドの関数呼び出しとして表せる。プログラムで継承の仕組みが利用されている場合はプログラムのテキストからだけでは呼び出すべきメソッドが決定できない場合があるので、実行時にメソッドを決定するためにメソッド・サーチや仮想関数テーブルといった仕組みが必要となる。多くのプログラミング言語においてメッセージは、メソッド呼び出しの比喩でしかないことが多い。SmalltalkやObjective-Cの様な言語では、メッセージはメソッド呼び出しとは独立した機構として存在している。メッセージが機構として存在する言語では、メッセージをオブジェクトに送信した際、宛先のオブジェクトにメッセージで指定したメソッドが存在しない場合でもメッセージを処理することが出来る。これを利用し、メッセージの配送先を別のオブジェクトに指定したり、メッセージを一時保存したり、不要なメッセージを無視する等といったメッセージ処理が行われる。大多数のオブジェクト指向プログラミング言語で提供されている仕組みであり、上記の機能のほとんど全てに関わりがある。概念的にはクラスはオブジェクトの種類を表す。このためオブジェクトはクラスに属するという言い方をする。データ型の理論から見た場合クラスは型を定義する手段の一つである。オブジェクト指向プログラミング言語と呼ぶ。ハイブリッド型オブジェクト指向プログラミング言語では在来のレコード型(Cでは構造体)の構文を拡張してクラスの定義を行うようにしたものが多い。多くのオブジェクト指向プログラミング言語ではクラスをデータメンバとメソッドの集まりとして記述する。平たく言えばデータ・メンバの集まりはオブジェクトが保持するデータの形式を定め、各メソッドはそれぞれオブジェクトが処理する特定のメッセージの処理方法を定める。データ・メンバとメソッドには個別にアクセス権が設定できるようになっていて、そのクラスに属するオブジェクトが内部的に利用するものと他のクラスに属するオブジェクトに公開するものを分類できるようになっている。多くの場合、公開されたメソッドの集まりは全体として処理可能なメッセージのカタログの機能、即ちインタフェースを提供する。各言語によって異なるが特定の名前のメソッドを定めて、オブジェクトの生成や初期化時の処理、廃棄時の処理などを記述できるようにすることも多い。多くの言語でクラスは言語の要素として直接実現されているが、これは実行効率のためであり、そのように実現することが必須というわけではない。実際、各クラスをそれぞれオブジェクトとして提供する言語も存在する(例:Smalltalk)。必要があればプログラムで実行時にクラスの動作を変更することが可能である。これは非常に大きな柔軟性を提供するが、言語処理系による最適化が難しいため実行効率は低下することが多い。近年[いつ?]では柔軟性と効率性を両立させるために基本的に言語要素としてクラスを提供した上で、リフレクション機能が必要なプログラムに対しては必要に応じて各クラスに対応するクラス・オブジェクトをプログラムが獲得できるようにしている言語が現れてきている。詳細は「プロトタイプベース」を参照クラスは非常に多くのオブジェクト指向プログラミング言語で提供されている機能ではあるが、オブジェクト指向プログラミング言語に必須の機能というわけではない。実際にオブジェクトの管理や、データ・メンバやメソッドの記述、継承に際してクラスという仕組みに依存せずに、もしくはクラスという仕組み自体を持たずに別の手段でこれらを実現している言語も存在する。オブジェクト指向プログラミング言語と呼ぶ。eToys(Squeakの非開発者向けビジュアルスクリプト言語。とも)なお、クラスベースの言語とインスタンス・ベースの言語との間には明確な境界線はない。類似の仕組みを「クラス」と呼称している。逆に、クラスベースの言語でもクローンを行うメソッドを備え、委譲の仕組みを記述すればある程度はインスタンス・ベースのスタイルでプログラムを記述できる。インスタンス・ベースの言語ではオブジェクトの生成は既存のオブジェクト、特にプロトタイプ(prototype、原型)と呼ばれるオブジェクトからのクローンによって行われる。一群のクローンはその親、ひいてはプロトタイプと同一の種類のオブジェクトと見なされる。メソッドはプロトタイプ・オブジェクトに属し、メッセージは委譲によってそのオブジェクトが覚えているコピー元へ向かってプロトタイプまで順にメッセージが中継されてから処理される。新しい種類のオブジェクトが必要な場合は適当なオブジェクトをクローンした後で必要なデータ・メンバやメソッドを追加あるいは削除し新たなプロトタイプとすることで行われる。追加されたのでないメソッドに対応するメッセージについてはコピー元のオブジェクトに処理を委譲する。クラスベースの言語との関係について考えてみると、クローンはプロトタイプと同一の「クラス」に属すると見なし、データ・メンバやメソッドが追加・削除されてあらたなプロトタイプが作られると別の「クラス」が内部的に生成されると考えることができる。ここでデータ・メンバやメソッドの追加のみを許して削除を許さないよう制限すればクローンの「クラス」がその親の「クラス」を継承した場合と同等になる。このためメッセージが委譲の連鎖をたどって配送されるという効率上の問題を無視すれば理論上、インスタンス・ベースの言語の記述能力はクラス・ベースの言語を包含していると言える。インスタンス・ベースの言語でも実行効率上の問題からなんらかのクラスに似た仕組みを備えている場合が多い。他のオブジェクトに対する参照やポインタであるか、他のオブジェクトそのものである。参照かポインタである場合にはそのデータメンバの参照するのはデータメンバが記述されているクラスそのもののインスタンスに対する参照であっても良い。一般にデータメンバはインスタンスデータメンバ(インスタンスフィールド)とクラスデータメンバ(静的変数)の2種類に大別できる。効率上の観点から言語が提供する基本オブジェクトの定数を表すデータメンバは特別扱いされる。variable)、Javaなどではフィールドと呼ばれることがあり、UMLでは属性と呼ばれる。詳細は「インスタンス変数」を参照インスタンスデータメンバ(一般に単にデータメンバと言われる場合はこちら)はそのクラスのインスタンス各々に保持される。インスタンスデータメンバの集まりはそのクラスのインスタンスが保持するデータの形式を定める。インスタンスデータメンバは単にデータメンバと呼ばれることも多い。詳細は「クラス変数」を参照クラスデータメンバはそのクラスオブジェクトとインスタンスオブジェクトの間で共有されるデータである。