「オブジェクト指向プログラミング」の版間の差分
Goldensundown2 (会話 | 投稿記録) |
タグ: Refタグつき記述の除去 |
||
| (7人の利用者による、間の106版が非表示) | |||
| 1行目: | 1行目: | ||
{{独自研究|date=2018年2月}} |
|||
{{複数の問題 |
|||
|独自研究=2018年2月 |
|||
|正確性=2019年2月 |
|||
|出典の明記=2019年2月 |
|||
}} |
|||
{{プログラミング言語|index=おふしえくとしこうふろくらみんく}} |
{{プログラミング言語|index=おふしえくとしこうふろくらみんく}} |
||
'''オブジェクト指向プログラミング'''（オブジェクトしこうプログラミング、{{Lang-en-short|object-oriented programming, '''OOP'''}}）は、[[プログラミング (コンピュータ)|コンピュータ・プログラミング]]の[[プログラミングパラダイム|パラダイム]]<ref>コンピュータ・プログラミングのパラダイムについては『新しいプログラミング・パラダイム』などを参照: http://www.kyoritsu-pub.co.jp/bookdetail/9784320024939</ref>のひとつで、[[オブジェクト指向]]の概念や手法を取り入れたものである。プログラムを、データとその振舞が結び付けられた[[オブジェクト (プログラミング)|オブジェクト]]の集まりとして構成する、などといった特徴がある。このパラダイムを指向している[[プログラミング言語]]が'''オブジェクト指向プログラミング言語'''である。 |
|||
[[ファイル:Object oriented design object.jpg|境界|右|フレームなし]] |
|||
'''オブジェクト指向プログラミング'''（オブジェクトしこうプログラミング、{{Lang-en-short|''object-oriented programming''}}、略語:OOP）は、[[オブジェクト指向]]の[[プログラミングパラダイム|考え方]]<ref>コンピュータ・プログラミングのパラダイムについては『新しいプログラミング・パラダイム』などを参照: http://www.kyoritsu-pub.co.jp/bookdetail/9784320024939</ref>を取り入れた[[プログラミング (コンピュータ)|コンピュータプログラミング]]手法である。[[オブジェクト (プログラミング)|オブジェクト]]とは大まかに言うとデータ（[[変数 (プログラミング)|変数]]または[[プロパティ (プログラミング)|プロパティ]]）とコード（[[関数 (プログラミング)|関数]]または[[メソッド (計算機科学)|メソッド]]）の複合体を意味しているが、その詳細については様々な解釈が存在する。OOPに基づくプログラムはこの[[オブジェクト (プログラミング)|オブジェクト]]の集合として組み立てられる事になるが、その実装スタイルもまた千差万別である。 |
|||
オブジェクト指向プログラミングという言葉自体は計算機科学者[[アラン・ケイ]]が作り出したものである。彼は1967年に公開された[[Simula|Simula67]]の[[クラス (コンピュータ)|クラス]]と[[オブジェクト (プログラミング)|オブジェクト]]を備えた言語仕様を見た際に''object-orientedという造語を咄嗟に口にしたとされ、その造語は''ケイ自身が1972年から80年にかけて開発した[[Smalltalk]]の言語設計を説明する中で初めて用いられて世間に知られるようになった。なお[[Smalltalk]]における、あらゆるプログラム内要素をオブジェクトとして扱い、[[メッセージパッシング]]でコミュニケーションさせるというケイ発案のオブジェクト指向の実践は、マシンパワーやリソースを必要としたため誰もがその恩恵に預かれたわけではなかった。1983年に公開された[[C++]]が契機となり、OOPはまた違った角度から注目されるようになった。最終的にこの[[C++]]の設計スタイルが物議を醸しながらもOOPの主流となるに到り、同時にOOPの三原則とされる[[カプセル化]]、[[継承 (プログラミング)|継承]]、[[ポリモーフィズム|多態性]]の[[プログラミングパラダイム]]が確立されている。 |
|||
== 特徴 == |
== 特徴 == |
||
オブジェクト指向プログラミングで用いられる代表的な概念および技法として、以下のものが挙げられる。 |
|||
プログラミングパラダイムとしてのオブジェクト指向の確立は紆余曲折を経ており（後述）その詳細の解釈も様々であるが、一定の枠組みとなる三つの原則（''fundamental principle''）が存在し、それに従った言語仕様を総体的または部分的に備えたプログラミング言語がオブジェクト指向準拠と判別される。1～3はオブジェクト指向プログラミングの三原則とされるものであり[[C++]]を契機にして提唱された。4を加えて四本の柱（''pillar''）とする考えもある。 |
|||
*[[カプセル化]]（振る舞いの隠蔽とデータ隠蔽） |
|||
*[[インヘリタンス]]（[[継承 (プログラミング)|継承]]） -- [[クラスベース]] |
|||
*[[ポリモーフィズム]]（[[多態性]]、[[多相性]]） |
|||
*[[ダイナミックバインディング]]（[[動的束縛]]） -- [[動的型付け]] |
|||
上記を含むオブジェクト指向プログラミングにおいて有用な機能（の一部）を言語仕様として備えたプログラミング言語を、'''オブジェクト指向プログラミング言語''' ({{Lang|en|'''OOPL'''; object-oriented programming language}}) という。 |
|||
5～7は[[Smalltalk]]が提唱する元祖オブジェクト指向のコンセプトであり、この三者は相互に関連して始めて一つの意味を表現している。その真髄はオブジェクトを媒体にしてコードとデータの融合を目指した高度な抽象化または代数化である。元祖オブジェクト指向は哲学的側面が強いものであり、それを実用的に演繹したものが1～3であると考える事も出来る。 |
|||
ただし、上述の特徴はオブジェクト指向言語に固有の概念というわけではなく、非オブジェクト指向言語の中にもこの性質を備えるものもある。 |
|||
#[[カプセル化]]（''encapsulation''） |
|||
#[[継承 (プログラミング)|継承]]（''inheritance''） |
|||
#[[ポリモーフィズム|多態性]]（''polymorphism''） |
|||
#*アドホック多態性（''ad hoc polymorphism''） |
|||
#**[[多重定義|関数オーバーロード]]（''function overloading''） |
|||
#**[[多重定義|演算子オーバーロード]]（''operator overloading''） |
|||
#*パラメータ多態性（''parameter polymorphism''） |
|||
#**[[ジェネリックプログラミング|ジェネリック関数]]（''generic function''） |
|||
#**[[ジェネリックプログラミング]]（''generic programming''） |
|||
#*[[派生型|サブタイプ多態性]]（''subtyping''） |
|||
#**[[仮想関数]]（''virtual function''） |
|||
#**動的ディスパッチ（''dynamic dispatch''） |
|||
#**[[ダブルディスパッチ]]（''double dispatch''） |
|||
#**[[多重ディスパッチ]]（''multiple dispatch''） |
|||
#[[抽象化 (計算機科学)|抽象化]]（''abstraction''） |
|||
#[[メッセージ (コンピュータ)|メッセージング]]（''messaging''） |
|||
#ローカル保持（''local retention, protection, hiding of state-process''） |
|||
#[[動的束縛|遅延バインディング]]（''late binding''） |
|||
== 背景 == |
|||
オブジェクト指向プログラミングという考え方が生まれた背景には、計算機の性能向上によって従来より大規模な[[ソフトウェア]]が書かれるようになってきたということが挙げられる。大規模なソフトウェアが書かれコードも複雑化してゆくにつれ、ソフトウェア開発コストが上昇し、[[1960年代]]には「[[ソフトウェア危機]] ({{Lang|en|software crisis}})」といったようなことも危惧されるようになってきた。そこでソフトウェアの[[再利用 (プログラミング)|再利用]]、[[部品化 (プログラミング)|部品化]]といったようなことを意識した仕組みの開発や、[[ソフトウェア開発工程]]の体系化（'''[[ソフトウェア工学]]''' ({{Lang|en|software engineering}}) の誕生）などが行われるようになった。 |
|||
任意のデータ（変数、プロパティ）群と、それを参照ないし変更するコード（関数、メソッド）群をひとまとめにしてオブジェクトとし、オブジェクト内のデータ群は外部からはアクセスできず隠蔽され、外部公開されたコードを通してのみアクセス可能にした仕組みがカプセル化と呼ばれる。より詳しい解釈については様々だが、オブジェクト指向におけるカプセル化は、基本的に内部隠蔽に焦点を当てたパラダイムである。開発規模の拡大に伴い解決の難しいバグ原因の大半は、データの予期せぬ変化とデータ間の予期せぬ不整合である事が経験則で知られるようになったので、データを変えたコードの位置特定を容易にする為の手段だった。データ直接参照の禁止は予期せぬデータの読み取りを抑止するだけでなく、いわゆる抽象化の一手段も兼ねていた。データを読み取る際にワンクッションの仲介コードを置く事で実行環境の変化に合わせた柔軟なデータ表現を可能にした。ただしこのワンクッション制度は安全性と引き換えにコード記述量を大きくするので、特定のデータとコードに対しては便宜的に直接アクセスを解禁する仕組みも生まれ、これはアクセス権限と呼ばれた。 |
|||
このような流れの中で、プログラムを構成するコードとデータのうちコードについては[[プロシージャ|手続き]]や[[関数 (プログラミング)|関数]]といった仕組みを基礎に整理され、その構成単位を[[ブラックボックス]]とすることで再利用性を向上し、部品化を推進する仕組みが提唱され'''[[構造化プログラミング]]''' ({{Lang|en|structured programming}}) として[[1967年]]に[[エドガー・ダイクストラ]] ({{Lang|en|Edsger Wybe Dijkstra}}) らによってまとめあげられた（プログラミング言語の例としては[[Pascal]] [[1971年]]）。なお、それに続けて「しかしデータについては相変わらず主記憶上の記憶場所に置かれている限られた種類の[[基本データ型]]の値という比較的低レベルの抽象化から抜け出せなかった。これはコードはそれ自身で意味的なまとまりを持つがデータはそれを処理するコードと組み合わせないと十分に意味が表現できないという性質があるためであった。」といったように、ほぼ間違いなく説明されている。 |
|||
カプセル化を推し進めたものとして'''プロトコル'''（''protocol''）がある。これはオブジェクト内部を全隠蔽し、抽象メソッドをまとめた純粋抽象クラスで表現されるインターフェース・オブジェクトを通してアクセスする仕組みを指した。オブジェクトそのものにワンクッションを置いた制度とも言える。プロトコルはオブジェクトの安全な公開を実現し、共同開発とコンポーネント開発に適したものとされた。プロトコルは後述の多態性にも関連しており、特に動的ディスパッチを表現するメカニズムにもなった。 |
|||
そこでデータを構造化し、ブラックボックス化するために考え出されたのが、データ形式の定義とそれを処理する手続きや関数をまとめて一個の構成単位とするという考え方で'''[[モジュール]]''' ({{Lang|en|module}}) と呼ばれる概念である（[[プログラミング言語]]の例としては[[Modula-2]] 1979年）。しかし定義とプログラム内の実体が一対一に対応する手続きや関数とは異なり、データはその形式の定義に対して値となる実体（[[インスタンス]]と呼ばれる）が複数存在し、各々様々な寿命を持つのが通例であるため、そのような複数の実体をうまく管理する枠組みも必要であることがわかってきた。そこで単なるモジュールではなく、それらのインスタンスを整理して管理する仕組み（例えば[[クラス (コンピュータ)|クラス]]とその[[継承 (プログラミング)|継承]]など）まで考慮して生まれたのが[[オブジェクト (プログラミング)|オブジェクト]]という概念である（プログラミング言語の例としては[[Simula]] 1962年） |
|||
=== 継承 === |
|||
継承の元々の趣旨はオブジェクトの体系化である。ここでの体系化とは多様な要素をそれぞれ共通と特有の分節構成にし、共通部分から特有部分を派生させる形で関連付ける枝葉状の展開構図に投影する行為を指した。構造体の定義増加で発生しやすい似たようなデータ群の重複に伴う冗長さとその整合性維持の手間隙を解決する為の手段であった。構造体＝オブジェクトを複数の階層に分け、共通のデータ集合を親階層とし、特有のデータ集合を子階層として、子階層に親階層へのリンクを持たせて連結する構造にした。A階層から成る親オブジェクトから派生した子オブジェクトはA＋B階層として構成され、これが継承と呼ばれた。コードから参照されたデータがB階層に無い時は、次のA階層に有るか探す仕組みとなり、この連鎖によって傍からは一つのオブジェクトとして存在した。データと同様に共通のメソッド群も親階層にまとめられた。その応用として抽象メソッド（＝仮想関数）だけの階層を独立させたインターフェースまたは純粋抽象クラスがあり、これを親階層として継承（実装）するのは'''[[派生型|サブタイピング]]'''（''subtyping''）となった。サブタイピングは後述の多態性のメカニズムの一つでもある。なお、派生クラスで任意の機能を追加できる仕組みはコードの再利用性を高めるとも考えられたが、深い継承はクラス構造の把握を困難にするという欠点が明らかになったのでこれは否定された。継承による再利用性はクラスライブラリの使用範囲内に留まっているのが現状である。 |
|||
なお、子階層の次のリンク先となる親階層は一本だけでなく複数本持つ事も出来るので、複数の親階層＋子階層によるオブジェクト構成は'''多重継承'''と呼ばれた。子階層が持つ親階層アドレスは一般にリスト化されており、自身に無いデータはリスト先頭の親階層から順々に検索された。その親階層が多重継承されてる場合も同様であり、それぞれの枝分かれには深さ優先検索が用いられた。前述のサブタイピングは多重で行われる事が多い。 |
|||
=== 多態性 === |
|||
アドホック多態性は単にソースコードの記述を一部自動化するものである。'''関数オーバーロード'''は引数の並び方パターンによって同じ名前のメソッドをコンパイル時に自動的に差別化する機能である。'''演算子オーバーロード'''は、扱う数値の型に従って宣言された演算記号を関数名と見なすようにし、単項演算子なら右の数値を第一引数とし、二項演算子なら左右の数値をそれぞれ第一第二引数として関数呼び出しのコードが生成されるという仕組みだった。丸括弧の演算子は関数オブジェクトの表現として使用出来た。これらは静的な多態性とされる。 |
|||
パラメータ多態性もソースコードの記述を一部自動化するものである。関数＆クラスのコード内の特定の型部分をワイルドカードにして記述しておき、ソースコード内で具体的な型の指定と共に関数＆クラスの呼び出しが記述されると、その型を先のワイルドカードに当てはめた関数＆クラスのコードがコンパイル時に自動生成されるという機能だった。＆の前者は'''ジェネリック関数'''と呼ばれ、後者はより広い範囲を扱う事から'''ジェネリックプログラミング'''と名付けられた。これらも静的な多態性に位置付けられている。 |
|||
サブタイプ多態性は動的なものである。最も初期のOOPであるSimula67は、シミュレーション内で扱う多種多様なオブジェクトを継承によって体系化したが、コード部分の細かな違いは共通スーパークラスに属する共通プロシージャ内の分岐フローで処理していた。サブクラスの数だけ分岐構文が増える頻雑さを解消するために、共通プロシージャをただの[[仮想関数テーブル|住所テーブル]]にしてサブクラスの実装時に同名プロシージャのアドレスを収納させ、共通プロシージャ呼び出し時にそのアドレスへジャンプするという機能が考案された。[[仮想関数テーブル|住所テーブル]]はプロシージャの仮想的存在と見なされたので、この機能は'''仮想関数'''と呼ばれた。'''動的ディスパッチ'''はSmalltalkのオブジェクト設計に由来するものであり、その実装の仕方は様々でやや曖昧な仕様でもある。メッセージを受け取ったレシーバーがオブジェクト内部で動的な状態に従い動的な処理を行って結果を返すというランタイム環境上のプロセスが後に動的ディスパッチのカテゴリで括られた。[[分散コンピューティング]]を表現する[[Object Request Broker|オブジェクト間通信]]とそれに基づく[[ソフトウェアコンポーネント]]も動的ディスパッチに該当するものである。'''多重ディスパッチ'''は動的な関数オーバーロードに近いものである。関数コール時または関数ブロック内で、それぞれの引数が動的に型審査されて型変化（''dynamic casting''）された後に、その引数パターンに対応した同名関数または分岐ルーチンに処理が移行されるという動的変化プロセスを指した。'''ダブルディスパッチ'''は多重ディスパッチの亜流的存在であり、二通りの考え方がある。動的型審査および型変化されるBオブジェクトを単一引数にしてAオブジェクトの仮想関数メソッドを呼び出す形態と、多重ディスパッチに用いる引数を二つに限定した形態である。いずれも実行時状態に応じた動的変化プロセスとなった。これは主にデータ集合を対象にして分類、解析、作用といった処理を連続的または再帰的に行うアルゴリズムで用いられた。 |
|||
=== 抽象化 === |
|||
純粋抽象クラスの仕組みがこれに相当する。実例としては[[ソフトウェアコンポーネント]]及び[[Java]]などのプログラミング言語で用いられている[[インタフェース (抽象型)|インターフェース]]がある。この抽象化は、カプセル化の{{仮リンク|.プロトコル|en|Protocol (object-oriented programming)|label=}}、継承の[[派生型|サブタイピング]]、多態性の仮想関数をまとめたパラダイムと考える事が出来る。 |
|||
[[C++]]開発者の[[ビャーネ・ストロヴストルップ]]は、広義のオブジェクト指向の主要サポート案件として抽象化、継承、実行時多態性（''run-time polymorphism''）の三点を挙げていた。抽象化は同時に完全な内部隠蔽になるので、コンクリートクラスの中途半端な内部隠蔽ではなく、純粋抽象クラスのプロトコルを重視していた事が分かる。 |
|||
=== メッセージング === |
|||
メッセージングは哲学的側面が強いパラダイムである。仕組み的には、オブジェクト（=インスタンス）のメソッドコール、または[[Object Request Broker|オブジェクト間通信]]におけるリモートメソッドコールと同じものと考えてよいが、メッセージングのパラダイム下では、イメージ的にオブジェクトそのものをメソッドとしてコールする点が異なっている。それは各オブジェクトが一般にレシーバーと呼ばれるデフォルトメソッドを持つ事で実現されている。オブジェクトのコールとは、このレシーバーをコールするのと同義となる。引数無しでコールされる事はなく、基本的に一つのオブジェクトが引数となってコールされる。これも留意すべき点である。元祖オブジェクト指向では「''EverythingIsAnObject''」の通り、[[プリミティブ型|プリミティブ]]から[[構造体|データストラクチャ]]、[[コードブロック]]まであらゆるプログラム要素がオブジェクトとされる。ここにオブジェクトA、Bがあるとすると、メッセージングの基本構文は「A B」のようになる。これは「Bを引数にしてAを呼び出す」の意味であり、イメージ的に「Aに対してBというメッセージを送る」と形容される。引数Bを受け取ったAのレシーバー内で任意の処理が行われた後に結果値としてのオブジェクトが返される。Aそのものが返される事もあれば、別のオブジェクトが返される事もある。この流れがメッセージングと呼ばれるものである。返値オブジェクトに対して別のメッセージを送る事も可能であり、また返値オブジェクトをメッセージにして別のオブジェクトに送る事も出来る。こうしたメッセージングの連鎖はAのレシーバー内でも同様に行なわれる。メッセージング・パラダイム下でのオブジェクトは言わば独自の記憶を備えた変換式であり、これらオブジェクトのコミュニケーションとは[[高階関数]]と[[第一級関数]]の仕組みと同じものである。メッセージング・パラダイムの本質はオブジェクトの代数（''algebra''）化であり、その代数値は前述のメッセージングの連鎖による結果値である。メッセージングを行なうオブジェクトもまたメッセージング連鎖の集合体という事になる。それはただの[[プリミティブ|プリミティブ値]]であっても決して例外ではない。レシーバーでの処理をコードとすると、メッセージング・パラダイム下でのデータはメッセージング連鎖によるコードの集合体であり、その各コードは他のデータ群を参照しており、その各データもまたコードの集合体～という風になる。勿論最終的には根っことなるオブジェクトの定形データに行き着いてそれが値算出の原点になるが、こうなるとイメージ的にコードとデータが融合して両者の区別はなくなる。オブジェクトは抽象化の一形態である代数的（''algebraic''）存在なので、代数計算と同様に理念的には単体で成り立つ事はなく、二つのオブジェクトが出会うメッセージングによって始めて一定のプロセスが発生し、または一つのデータが体現される。これが引数無しでもよいメソッドと引数が要るメッセージングの明確な違いである。 |
|||
なお、実装面では便宜上の理由から、メッセージングの際の引数オブジェクトにはセレクタを付けるのが許容されている。大抵は「A ''selector'':B」の様になる。セレクタはメソッド名と同義であり、引数オブジェクトに貼られるラベルと考えていいものである。セレクタによってレシーバー外の対応メソッドに自動分岐されるのでコーディングが簡便になる。[[演算子]]も事実上のセレクタであり「5+3」は、+セレクタを貼った3オブジェクトを5に送ると解釈できる。括弧記号はコンパイラのためのただの[[ディレクティブ]]となる。メッセージングは二つのオブジェクトが出会った時点で発生するプロセスなので引数は常に一つであり、複数の引数を用いたい場合はパーシャルアプリケーションまたは[[カリー化]]を適用するべきであるが、これは困難なコーディングになる事が多いので、セレクタによる[[パターンマッチング]]的な各メソッドへの自動分岐も許容されている。 |
|||
このメッセージングのパラダイムは様々な理由から広くは認知されず、やがてその言葉だけが一人歩きするようになって本来の定義からシフトし、前述のレシーバーの仕組み自体がメッセージングと見なされるようにもなり、[[Object Request Broker|オブジェクト間通信]]で行なわれるバイトデータ列の送受信もメッセージングの代表例とされるようになった。また、インスタンスの単純なメソッド呼び出しもメッセージングであると説明される事もある。この様にメッセージングの本質は見失われながらも、その側面的仕様は数々のOOP言語に導入されてもいる。 |
|||
=== ローカル保持 === |
|||
{{節スタブ}} |
|||
=== 遅延バインディング === |
|||
{{節スタブ}} |
|||
== 歴史 == |
|||
オブジェクト指向プログラミングという考え方が生まれた背景には、計算機の性能向上によって従来より大規模な[[ソフトウェア]]が書かれるようになってきたということが挙げられる。大規模なソフトウェアが書かれコードも複雑化してゆくにつれ、ソフトウェア開発コストが上昇し、[[1960年代]]には「[[ソフトウェア危機]] ({{Lang|en|software crisis}})」といったようなことも危惧されるようになってきた。そこでソフトウェアの[[再利用 (プログラミング)|再利用]]、[[部品化 (プログラミング)|部品化]]といったようなことを意識した仕組みの開発や、[[ソフトウェア開発工程]]の体系化（'''[[ソフトウェア工学]]''' ({{Lang|en|software engineering}}) の誕生）などが行われるようになった。 |
|||
Simulaのオブジェクトとクラスというアイデアは異なる二つの概念に継承される。一つはシステム全てをオブジェクトの集合と捉え、オブジェクトの相互作用を'''メッセージ'''に喩えた「[[オブジェクト指向]]」である。オブジェクト間の相互作用をメッセージの送受と捉えることで、オブジェクトは受信したメッセージに見合った手続き単位（≒関数）を自身で起動すると考える。結果オブジェクトは自身の持つ手続きのカプセル化を行うことができ、メッセージが同じでもレシーバオブジェクトによって行われる手続きは異なる――[[ポリモーフィズム|多相性]]（ポリモーフィズム）を実現した（このメッセージを受け実行される手続き単位は、メッセージで依頼されたことを行うための「手法」の意味で[[メソッド (計算機科学)|メソッド]]と呼ばれる）。この思想に基づき作られたのが[[Smalltalk]]（[[1972年]]）であり、[[オブジェクト指向]]という言葉はこのとき作られた。 |
|||
このような流れの中で、プログラムを構成するコードとデータのうち、コードについては[[プロシージャ|手続き]]や[[関数 (プログラミング)|関数]]といった仕組みを基礎に整理され、その構成単位を[[ブラックボックス]]とすることで再利用性を向上し、部品化を推進する仕組みが提唱され'''[[構造化プログラミング]]''' ({{Lang|en|structured programming}}) として{{要出典範囲|date=2019年2月|[[1967年]]}}に[[エドガー・ダイクストラ]] ({{Lang|en|Edsger Wybe Dijkstra}}) らによってまとめあげられた（プログラミング言語の例としては[[Pascal]] [[1971年]]）。なお、それに続けて「しかしデータについては相変わらず主記憶上の記憶場所に置かれている限られた種類の[[基本データ型]]の値という比較的低レベルの抽象化から抜け出せなかった。これはコードはそれ自身で意味的なまとまりを持つがデータはそれを処理するコードと組み合わせないと十分に意味が表現できないという性質があるためであった。」といったように、ほぼ間違いなく説明されている。 |
|||
一方、Smalltalkとは別にSimulaの影響を受け作られた[[C++]]（[[1979年]]）は[[抽象データ型]]のスーパーセットとしてのクラス、オブジェクトに注目し、オブジェクト指向をカプセル化、継承、多相性をサポートするものと再定義した（その際、実行時速度重視及びコンパイラ設計上の制約により、変数メタファである[[動的束縛]]の特徴は除外された）。これらは当初[[抽象データ型]]、[[派生]]、[[メソッド (計算機科学)#仮想関数|仮想関数]]と呼ばれ、オブジェクトのメンバ関数を実体ではなくポインタとすることで、継承関係にあるクラスのメンバ関数の[[オーバーライド]]（上書き）を可能にしたことで、多相性を実現した（この流儀では'''メッセージメタファ'''はオブジェクト指向に必須ではないものと定義し、オブジェクトの持つ手続きをメソッドとは呼ばず[[メソッド (計算機科学)|メンバ関数]]と呼ぶ）。この他、Smalltalkにある[[動的束縛]]の類似的な機能としてオーバーロード（[[多重定義]]）が実装されている。 |
|||
そこでデータを構造化し、ブラックボックス化するために考え出されたのが、データ形式の定義とそれを処理する手続きや関数をまとめて一個の構成単位とするという考え方で'''[[モジュール]]''' ({{Lang|en|module}}) と呼ばれる概念である（[[プログラミング言語]]の例としては[[Modula-2]] 1979年）。しかし定義とプログラム内の実体が一対一に対応する手続きや関数とは異なり、データはその形式の定義に対して値となる実体（[[インスタンス]]と呼ばれる）が複数存在し、各々様々な寿命を持つのが通例であるため、そのような複数の実体をうまく管理する枠組みも必要であることがわかってきた。そこで単なるモジュールではなく、それらのインスタンスを整理して管理する仕組み（例えば[[クラス (コンピュータ)|クラス]]とその[[継承 (プログラミング)|継承]]など）まで考慮して生まれたのが[[オブジェクト (プログラミング)|オブジェクト]]という概念である（プログラミング言語の例としては1967年の[[Simula|Simula 67]]<!--言語機能としての「クラス」はSimula 67から-->）。 |
|||
Smalltalkはこの「全てをオブジェクトとその相互作用で表現する」というデザインに立ち設計されたため、全てをファイルと捉える'''ファイル指向[[オペレーティングシステム]]'''からの脱却と、プログラムをフロー制御された手続きと捉える'''手続き型言語'''からの脱却が行われた。そのためSmalltalkは自身が'''オブジェクト指向オペレーティングシステム'''でもあること、メッセージ・パッシングなどの特徴を持った。これは当時のプログラム言語としては特異的であり、[[ガベージコレクション|ガベージコレクタ]]を必要とし[[インタプリタ]]形式で実行される処理の重さも手伝って先進的ではありながら普及しがたいものであると捉えられた。また、メッセージでの多相性は、変数へのオブジェクトの[[動的束縛]]が前提となるため、静的型チェックが必要な実行時性能重視のコンパイラ言語にとって、実装から除外すべき特徴となった。 |
|||
Simulaのオブジェクトとクラスというアイデアは異なる二つの概念に継承される。一つはシステム全てをオブジェクトの集合と捉え、オブジェクトの相互作用を'''メッセージ'''に喩えた「[[オブジェクト指向]]」である。オブジェクト間の相互作用をメッセージの送受と捉えることで、オブジェクトは受信したメッセージに見合った手続き単位（≒関数）を自身で起動すると考える。結果オブジェクトは自身の持つ手続きのカプセル化を行うことができ、メッセージが同じでもレシーバオブジェクトによって行われる手続きは異なる――[[ポリモーフィズム|多相性]]（ポリモーフィズム）を実現した（このメッセージを受け実行される手続き単位は、メッセージで依頼されたことを行うための「手法」の意味で[[メソッド (計算機科学)|メソッド]]と呼ばれる）。この思想に基づき作られたのが[[Smalltalk]]（[[1972年]]）であり、[[オブジェクト指向]]という言葉はこのとき[[アラン・ケイ]]によって作られた。 |
|||
C++の創始者[[ビャーネ・ストロヴストルップ]]は、Smalltalkのような論理美の追求よりも、現用としての実用性を重視した。そのため、C++の再定義した「オブジェクト指向」はこれらの問題を全てクリアにし、既存言語の拡張としてオブジェクト指向機能を実装できることでブレイクスルーを迎え急速に普及する。これにより'''メッセージ送信'''という考え方はやや軽視されるようになり、オブジェクト指向とはC++の再定義したものと広く認知されるようになった。 |
|||
一方、Smalltalkとは別にSimulaの影響を受け作られた[[C++]]（[[1979年]]）は[[抽象データ型]]のスーパーセットとしてのクラス、オブジェクトに注目し、オブジェクト指向をカプセル化、継承、多相性をサポートするものと再定義した（その際、実行時速度重視およびコンパイラ設計上の制約により、変数メタファである[[動的束縛]]の特徴は除外された）。これらは当初[[抽象データ型]]、[[派生]]、[[メソッド (計算機科学)#仮想関数|仮想関数]]と呼ばれ、オブジェクトのメンバ関数を実体ではなくポインタとすることで、継承関係にあるクラスのメンバ関数の[[オーバーライド]]（上書き）を可能にしたことで、多相性を実現した（この流儀では'''メッセージメタファ'''はオブジェクト指向に必須ではないものと定義し、オブジェクトの持つ手続きをメソッドとは呼ばず[[メソッド (計算機科学)|メンバ関数]]と呼ぶ）。この他、Smalltalkにある[[動的束縛]]の類似的な機能としてオーバーロード（[[多重定義]]）が実装されている。 |
|||
[[1980年]]代後半に次々と生まれたオブジェクト指向分析・設計論は、[[Smalltalk]]を源流とするオブジェクト指向を基に組み立てられた。このときSmalltalkは健在であったが広く普及しているとは言えず[[C++]]で[[実装]]する機会が多かったが、C++はSmalltalkとは思想的にやや異なることと、仕様の複雑さが問題とされた。このニーズを受けC++の提示した現実解と、Smalltalk的理想論を融合するものとして、構文面ではシンプル化しながらも強くC++の影響を受けつつ、一方で用語や思想面でSmalltalk色を濃くした{{Citation needed|date=2018年2月}}[[Java]]（[[1991年]]）が作られた。バランス感覚に長けたJavaの登場によって[[オブジェクト指向開発]]に必要な要素が全てそろい、[[1990年代]]後半からオブジェクト指向は広く普及するようになった。 |
|||
Smalltalkはこの「全てをオブジェクトとその相互作用で表現する」というデザインに立ち設計されたため、全てをファイルと捉える'''ファイル指向[[オペレーティングシステム]]'''からの脱却と、プログラムをフロー制御された手続きと捉える'''手続き型言語'''からの脱却が行われた。そのためSmalltalkは自身が'''オブジェクト指向オペレーティングシステム'''でもあること、メッセージ・パッシングなどの特徴を持った。これは当時のプログラム言語としては特異的であり、[[ガベージコレクション|ガベージコレクタ]]を必要とし、高度な最適化が試される前のバイトコード[[インタプリタ]]で実行される処理の重さも手伝って先進的ではありながら普及しがたいものであると捉えられた。また、メッセージでの多相性は、変数へのオブジェクトの[[動的束縛]]が前提となるため、静的型チェック機構でのサポートが難しく、C++等の実行時性能重視の言語にとって実装から除外すべき特徴となった。 |
|||
== オブジェクト指向プログラミング言語一覧 == |
|||
C++の創始者[[ビャーネ・ストロヴストルップ]]は、Smalltalkが目指したある種の理想の追求には興味が無く、現用としての実用性を重視した。そのため、C++の再定義した「オブジェクト指向」は既存言語の拡張としてオブジェクト指向機能を実装できることでブレイクスルーを迎え急速に普及する。Smalltalkが単なるメソッドの動的呼び出しをメッセージ送信に見立て、呼び出すメソッドが見つからないときのみメッセージをハンドリングできるようにした「省コスト版」の機構を発明し以降それを採用するに至った経緯も手伝って、'''メッセージ送信'''という考え方はやや軽視されるようになり、オブジェクト指向とはC++の再定義したものと広く認知されるようになった。 |
|||
オブジェクト指向プログラミングをサポートする機能を備える代表的な[[プログラミング言語]]（[[オブジェクト指向プログラミング言語]]）としては以下のようなものが挙げられる： |
|||
; [[Simula]] [[1962年]] |
|||
[[1980年]]代後半に次々と生まれたオブジェクト指向分析・設計論は、[[Smalltalk]]を源流とするオブジェクト指向を基に組み立てられた。そのころSmalltalkは商用展開こそされていたが広く普及しているとは言えず、一般には[[C++]]での[[実装]]が多くを占めた。しかしC++はSmalltalkと思想的にかなり異なる点や、同様のことを実現する際の実装面での複雑さや制約が問題とされた。このニーズを受けC++の提示した抽象データ型にクラスを適用する現実的な考え方と親しまれたALGOL系の構文を踏襲しつつ、内部的には柔軟なSmalltalkのオブジェクトモデルを採用し、'''メソッド'''などの一部用語やリフレクション、実行時動的性などSmalltalk色も取り入れた[[Java]]が注目を集めた（[[1995年]]に登場。元々はモバイル機器向け言語処理系としてに開発された）。程なくSmalltalkやSELFで達成された[[仮想機械|仮想マシン（バイトコードインタープリタ）]]高速化技術の転用により実用的速度を得、バランス感覚に長けたJavaの台頭によって[[オブジェクト指向開発]]に必要な要素の多くが満たされ、[[1990年代]]後半からオブジェクト指向は広く普及するようになった。 |
|||
: [[オブジェクト (プログラミング)|オブジェクト]]と[[クラス (コンピュータ)|クラス]]を導入した最初の言語。また、C++が再定義したオブジェクト指向プログラミング言語の要件を満たすことから、最初のオブジェクト指向プログラミング言語とされることもある。[[クラスベース]]。当初はシミュレーション記述用に開発されたものであったが、後に汎用化された。 |
|||
; [[Smalltalk]] [[1972年]] |
|||
: オブジェクト間の相互作用に'''メッセージ'''という機構を導入した最初の言語。オブジェクト指向と言う言葉は、Smalltalkのプログラミングスタイルを説明するために作られた。[[動的な型付け]]により高い柔軟性を持つ。 |
|||
; [[C++]] [[1979年]] |
|||
: [[C言語]]のオブジェクト指向拡張。Simula言語風にクラスを定義でき、C言語の型システムを強化している。当初はC言語に対して上位互換であった。また、[[強い型付け]]によりC言語譲りの実行効率の高いコードが生成できる。 |
|||
; [[Objective-C]] [[1983年]] |
|||
: C言語のオブジェクト指向拡張。C言語のコードとSmalltalk型のオブジェクトシステムを混在させたもの。オブジェクトシステム自体はCで書かれたランタイム。 |
|||
; [[Eiffel]] [[1986年]] |
|||
: [[強い型付け]]を行う[[型システム]]や[[表明]]など堅牢性を強く意識して設計されたオブジェクト指向プログラミング言語。C++に[[テンプレート (プログラミング)|テンプレート]]が導入される前に[[総称型]]を導入していた。 |
|||
; [[Self]] [[1987年]] |
|||
: 最初の[[プロトタイプベース|インスタンスベース]]のオブジェクト指向プログラミング言語。 |
|||
; [[CLOS]] [[1988年]] |
|||
: [[関数型言語]][[Common Lisp]]のオブジェクト指向仕様。 |
|||
; [[Modula-3]] [[1988年]] |
|||
: モジュールを実現していた[[Modula-2]]言語のオブジェクト指向拡張。 |
|||
; [[Python]] [[1990年]] |
|||
: 最初のオブジェクト指向[[スクリプト言語]]。 |
|||
; [[Sather]] [[1990年]] |
|||
: Eiffelを拡張したもの。実行効率面での工夫が見られる。 |
|||
; [[NewtonScript]] [[1993年]] |
|||
: [[携帯情報端末|PDA]]環境用に修正されたSelf言語。PDAの性質を生かすため[[永続オブジェクト]]をサポートしている。 |
|||
; [[Ruby]] [[1993年]] |
|||
: オブジェクト指向スクリプト言語。クラスのMix-inなどのユニークな機能を持つほか、[[正規表現]]に渡るまで全てがクラスとして実装されていることが特徴。 |
|||
; [[Perl]] [[1994年]] |
|||
: Perl 5.0にてオブジェクト指向に対応。既存のPerl言語に後付けで拡張されたため記法は特殊だが、機能面では他のオブジェクト指向言語に引けを取らない。 |
|||
; [[Ada]]のオブジェクト指向拡張 [[1995年]] |
|||
: 恐らく最も仕様が複雑なオブジェクト指向プログラミング言語。 |
|||
; [[Java]] [[1995年]] |
|||
: [[仮想機械|仮想マシン]]（[[Java仮想マシン]]）上で動作することによる高い[[移植性|可搬性]]、[[リフレクション]]や[[スレッド (コンピュータ)|スレッド]]の標準サポートと充実した[[ライブラリ]]群で知られているオブジェクト指向プログラミング言語。 |
|||
; [[Object Pascal]] ([[Delphi]]) [[1995年]] |
|||
: [[Pascal]]言語のオブジェクト指向拡張。 |
|||
; [[JavaScript]] [[1996年]] |
|||
: [[ウェブページ]]上で実行することを主目的に開発されたスクリプト言語。[[プロトタイプベース]]の言語である。 |
|||
; [[OCaml]] [[1996年]] |
|||
: 関数型言語[[プログラミング言語ML|ML]]のオブジェクト指向拡張。[[クラス (コンピュータ)|クラス]]が[[型推論]]機構に組み込まれているという特徴がある。 |
|||
; [[PHP (プログラミング言語)|PHP]] [[2000年]] |
|||
: 動的にWebページを生成することを主目的としたスクリプト言語。バージョン4からオブジェクト指向に対応し、バージョン5でアクセス権やインターフェースなど、オブジェクト指向の強化が行われている。 |
|||
; [[C Sharp|C#]] 2000年 |
|||
: Javaとよく似た作りでJavaと同じく仮想マシン上で動作するが様々な部分で拡張されている。[[.NET Framework]]上で動く。 |
|||
; [[Microsoft Visual Basic .NET|Visual Basic.NET]] [[2002年]] |
|||
: 既存のVisual Basic（6.0以前）を大きく改訂してオブジェクト指向に対応。C＃同様[[.NET Framework]]上で動く。 |
|||
; [[COBOL]] [[2002年]] |
|||
: 2002年に制定された国際規格に、オブジェクト指向機能が採用された。1994年には、国際規格案を先取りした商用コンパイラ上で利用可能になった。オブジェクト指向構文を使わないCOBOLプログラムと混在できる。 |
|||
; [[Ceylon]] [[2011年]] |
|||
: Java をもとにつくられ、Java のもつ長所と短所を考慮しつつ、商用言語として再設計された言語。 |
|||
; [[Swift (プログラミング言語)|Swift]] [[2014年]] |
|||
: [[Objective-C]]のオブジェクトを引き継ぎながらも、ベースのC言語を取り除いて新しく再設計された言語。 |
|||
また、以下のような分類もある。 |
|||
; ハイブリッド型オブジェクト指向プログラミング言語 ({{Lang|en|hybrid object-oriented language}}) |
|||
: 「ハイブリッド」という用語をどう定義するかによるが、たとえば「手続き型や関数型などの既存の他のパラダイムを主とした言語に、オブジェクト指向機能を拡張した」という言語を「ハイブリッドだ」、と言う者もいれば、「当初からオブジェクト指向を含む、複数のパラダイムを指向する言語として設計された」という言語を「ハイブリッドだ」と言う者もいる。例としては、以上のどちらの基準か、それとも別の定義によるものかは知らないが、OCaml、C++およびObjective-C、CLOS、Object Pascal、object-oriented COBOLなどを挙げる者がいる。 |
|||
; 純粋なオブジェクト指向プログラミング言語 ({{Lang|en|pure object-oriented language}}) |
|||
: 「純粋」という用語をどう定義するかによるが、たとえば[[Smalltalk]]や[[Ruby]]のように「あらゆる対象がオブジェクトである」という言語（たとえば、Rubyではnilも、ヌルポインタのようなものではなく、NilClassのインスタンスというオブジェクトである。この場合対照例としては、通常の数値型などがオブジェクトでない[[Java]]であろう）を「純粋だ」と言う者もいれば、「当初からオブジェクト指向プログラミング言語として設計された」言語を「純粋だ」と言う者もいる（こちらの定義ではJavaも含まれるだろうか）。例としては、以上のどちらの基準か、それとも別の定義によるものかは知らないが、[[Smalltalk]]、[[Eiffel]]、[[Self]]、[[Ruby]]、[[Swift (プログラミング言語)|Swift]]などを挙げる者がいる。 |
|||
オブジェクト指向プログラミング言語では、オブジェクトへの[[参照 (情報工学)|参照]]や[[ポインタ (プログラミング)|ポインタ]]が多用される。そのため、オブジェクトの[[メモリ]]への割り当てに関して、自動[[ガベージコレクション]]機能を備えているものが多い。ただし、すべての言語が備えているわけではない。例えば、C++はガベージコレクションを備えていない。 |
|||
== OOP言語一覧 == |
|||
[[ファイル:History of object-oriented programming languages.svg|サムネイル|OOP言語の系譜|リンク=Special:FilePath/History_of_object-oriented_programming_languages.svg|代替文=]] |
|||
オブジェクト指向を総体的または部分的にサポートする機能を備えたプログラミング言語の公開は、1980年代後半から顕著となった。OOP言語の分類法は複数あるが、Smalltalkをルーツとするメッセージパッシングの構文が重視されてるか否かで大別される事が多い。そうでないものがOOP言語の主流となっており「C++」「Java」「C#」「Swift」などがその代表とされる。メッセージパッシングを重視するOOP言語には「Smalltalk」「Objective-C」「Self」などがある。言語仕様の中でオブジェクト指向の存在感が比較的高い代表的なプログラミング言語を以下に列挙する。 |
|||
== オブジェクト指向の応用 == |
|||
;[[Simula|Simula 67]] 1967年 |
|||
プログラミング（ただし、ごく狭義の。普通は以下のようなものもプログラミングの工程に含まれる）にとどまらず、以下のようなより広い範囲にオブジェクト指向は応用されている。 |
|||
:1962年に公開された[[Simula]]の後継版であり、[[クラス (コンピュータ)|クラス]]のプログラミング概念を導入した最初の言語である。現実世界の擬似モデルを観測するシミュレーション・プログラム制作用に開発されたもので、クラスを実メモリに展開したオブジェクトは、その観測対象要素となった。Simulaのクラスは、サブルーチンに専用変数と補助プロシージャを加えた機能的小型モジュールに近いものであったが、継承と仮想関数という先進的な設計を備えていた事でOOPの草分けと見なされるようになった。C++、Java、C#の設計母体となった。 |
|||
* [[オブジェクト指向分析設計]] |
|||
;[[Smalltalk]] 1972年 |
|||
* [[オブジェクト指向モデリング]] |
|||
:[[メッセージパッシング]]のプログラミング概念を導入した最初の言語。数値、真偽値から変数、構造体、コードブロック、メタデータまでのあらゆる要素をオブジェクトとする概念を編み出した最初の言語でもある。オブジェクト指向という言葉は、Smalltalk開発者がその言語設計を説明する中で生み出された。オブジェクトの基礎的な振る舞いを規定する限られた予約語の他は、オブジェクトとメッセージのやり取りで制御構造を含めたあらゆるプロセスを表現出来た。また、専用のランタイム環境上でプログラムを実行する設計を応用して動的な多態性とセキュリティに繋がるモニタリングも実現した。これは後に仮想マシンと呼ばれるものとなり、JavaやC#に踏襲された。 |
|||
* [[オブジェクトモデル化技法]] |
|||
;[[C++]] 1983年 |
|||
また、当初はJavaないしC++における[[デザインパターン (ソフトウェア)|デザインパターン]]を表記・記述するための（図形を含む）言語として設計が始まった[[統一モデリング言語]]は、ツールベンダ等の意向により以上のような応用をサポートするためのものとして、仕様は大幅に膨れている。 |
|||
:[[C言語]]にOOPデザインを追加したもの。Simulaの影響を受けている。[[クラス (コンピュータ)|クラス]]のメカニズムが備えられて、カプセル化、継承、多態性といったOOP仕様を実装している。[[テンプレート (プログラミング)|テンプレート機能]]や[[例外処理]]、演算子オーバーロードを応用した関数オブジェクトなど様々なプログラミングパラダイムも導入された。元がC言語であるため、OOPから逸脱したコーディングも多用できる点が物議を醸したが、その是非はプログラマ次第であるという結論に落ち着いた。 |
|||
;[[Objective-C]] 1984年 |
|||
:[[C言語]]をOOPデザイン化したもの。こちらはSmalltalkの影響を受けており、それに準じた[[メッセージパッシング]]と[[リフレクション (情報工学)|リフレクション]]のメカニズムが備えられた。OOP的には前述のC++よりも正統であると見なされた。制御構文が追加され、メッセージの仕様もやや簡素化されるなど実践上の便宜が図られており、Smalltalkよりもコーディングし易くなった。 |
|||
;[[Object Pascal]] 1986年 |
|||
:[[Pascal]]をOOPデザイン化したもの。 |
|||
;[[Eiffel]] 1986年 |
|||
:[[Pascal]]をベースにしてOOPデザイン化し、また[[ジェネリックプログラミング]]を追加した。型付けは静的に限られ、非参照データを自動解放する[[ガーベジコレクション|ガーベジコレクタ]]を持ち、多重継承時の問題を回避する仕組みや例外処理など高い堅牢性を備えた。これらは後のJavaやC#の手本となった。 |
|||
;[[Self]] 1987年 |
|||
:メッセージパッシングの構文が中心となっている。動的な多態性を重視した言語であり、従来の[[クラスベース]]のオブジェクト設計に対して、システム側が用意したオブジェクトを複製して任意の拡張を施す[[プロトタイプベース]]のデザインを初めて実装した。Smalltalkと同様に専用のランタイム環境で実行されたが、これも実用面では初となる[[実行時コンパイラ]]（''just-in-time compiler''）の機能が備えられて速度面でも画期的なものとなった。 |
|||
;[[CLOS]] 1988年 |
|||
:[[Common Lisp]]をOOPデザイン化したもの。 |
|||
;[[Python]] 1990年 |
|||
:[[インタプリタ]]式で動作する。言語仕様を簡素化し自動メモリ管理機能を実装して扱いやすく理解しやすいOOPを目指している。後のOOPスクリプト言語の手本となった。 |
|||
;[[Java]] 1995年 |
|||
:堅牢性と安全性を重視したOOP言語。その二つの理念を実現するために、仮想マシン上の実行、ガーベジコレクタ、例外処理などを採用し、ポインタと直アドレス変数、多重継承、ジェネリックプログラミング、演算子オーバーロードなどを破棄した。破棄部分についてはその埋め合わせの設計も備えられた。[[クラス (コンピュータ)|クラス]]のメカニズムを中心にしたOOPであるが、様々なプログラミングパラダイムも追加されている。非常に整えられたハイブリッドOOP言語である。 |
|||
;[[Delphi]] 1995年 |
|||
:[[Object Pascal]]を発展させたもので、データベースの操作プログラム開発などを主な用途とした。一時期Javaの対抗馬となった。 |
|||
;[[Ruby]] 1995年 |
|||
:OOPデザインされたスクリプト言語である。[[インタプリタ]]式で動作する。スクリプトでありながら、クラス、マルチスレッド、例外処理、そして[[ソフトウェアコンポーネント]]（モジュール）を扱える[[Mixin]]といった利便性の高い機能も備えている。 |
|||
;[[JavaScript]] 1996年 |
|||
:[[ウェブアプリケーション]]開発を主な目的とするOOPスクリプト言語。主に[[プロトタイプベース]]でオブジェクトを扱う事でコーディングを簡便にしている。[[ECMAScript]]として標準化されている。ECMAScript 2015ではクラス構文をサポートするようになった。 |
|||
;[[C Sharp|C#]] 2000年 |
|||
:[[Java]]を強く意識して開発されたOOP言語。[[.NET Framework]]などの[[共通言語基盤]]上で実行される。Javaと同等または部分的に拡張させたスタイルを持ち、こちらもよく整えられたハイブリッドOOP言語として知られる。 |
|||
;[[Microsoft Visual Basic .NET|Visual Basic.NET]] 2002年 |
|||
:[[Microsoft Visual Basic|Visual Basic]]をOOPデザイン化したもの。[[.NET Framework]]などの[[共通言語基盤]]上で実行される。 |
|||
;[[Ceylon]] 2011年 |
|||
:[[Java]]を元に開発され、その長所と短所を見直しつつ再設計されたOOP言語。Javaの改造版である。また[[JavaScript]]にもコンバートできる。 |
|||
;[[Kotlin]] 2011年 |
|||
:[[Javaバイトコード]]を出力し、[[Java仮想マシン]]上で動作するJavaテクノロジー互換OOP言語である。OOPでありながらグローバル関数および変数の使用も容認されており、オブジェクト指向プログラミングを手続き型プログラミングのスタイルに崩したかのようにデザインされている。 |
|||
;[[Swift (プログラミング言語)|Swift]] 2014年 |
|||
:高度に整えられたマルチパラダイムプログラミング言語。クラスのメカニズムをベースにしたオブジェクト指向プログラミングも導入されている。 |
|||
== |
== オブジェクト指向プログラミング言語の仕組み == |
||
オブジェクト指向プログラミング言語は、相互に'''[[#メッセージ|メッセージ]]'''を送りあう'''[[オブジェクト (プログラミング)|オブジェクト]]'''の集まりとして[[プログラム (コンピュータ)|プログラム]]を構成することができる仕組みを持つ。 |
オブジェクト指向プログラミング言語は、相互に'''[[#メッセージ|メッセージ]]'''を送りあう'''[[オブジェクト (プログラミング)|オブジェクト]]'''の集まりとして[[プログラム (コンピュータ)|プログラム]]を構成することができる仕組みを持つ。 |
||
そのために、少なくともオブジェクトについての3つの仕組みと、オブジェクトの管理についての3つの仕組みが必要となる。 |
そのために、少なくともオブジェクトについての3つの仕組みと、オブジェクトの管理についての3つの仕組みが必要となる。 |
||
;オブジェクトの仕組み |
;オブジェクトの仕組み |
||
:* オブジェクトに蓄えられる情報、データを表現する仕組み。 |
:* オブジェクトに蓄えられる情報、データを表現する仕組み。 |
||
:* 他のオブジェクトにメッセージを配送する仕組み。 |
:* 他のオブジェクトにメッセージを配送する仕組み。 |
||
:* 受け入れ可能な各種メッセージに対応して、処理する事柄を記述する仕組み（[[メソッド (計算機科学)|メソッド]]）。 |
:* 受け入れ可能な各種メッセージに対応して、処理する事柄を記述する仕組み（[[メソッド (計算機科学)|メソッド]]）。 |
||
: |
|||
;オブジェクトを管理する仕組み |
;オブジェクトを管理する仕組み |
||
:* オブジェクト間の関係を整理分類して系統立てる仕組み。 |
:* オブジェクト間の関係を整理分類して系統立てる仕組み。 |
||
| 144行目: | 111行目: | ||
これらをどのように言語の要素として提供し、どのような[[機械語]]コードで実現するかによって様々な[[オブジェクト指向プログラミング言語]]のバリエーションが生まれる。以下、オブジェクト指向プログラミング言語が提供する様々な要素が上記の仕組みをどのように実現しているかについて概観する。 |
これらをどのように言語の要素として提供し、どのような[[機械語]]コードで実現するかによって様々な[[オブジェクト指向プログラミング言語]]のバリエーションが生まれる。以下、オブジェクト指向プログラミング言語が提供する様々な要素が上記の仕組みをどのように実現しているかについて概観する。 |
||
=== オブジェクトの概念と実 |
=== オブジェクトの概念と実際 === |
||
'''[[オブジェクト (プログラミング)|オブジェクト]]''' ({{Lang|en|object}}) はオブジェクト指向プログラミングの中心となる'''概念'''であり、この概念を'''実際'''にどう実現するかは[[オブジェクト指向プログラミング言語]]により異なる。 |
'''[[オブジェクト (プログラミング)|オブジェクト]]''' ({{Lang|en|object}}) はオブジェクト指向プログラミングの中心となる'''概念'''であり、この概念を'''実際'''にどう実現するかは[[オブジェクト指向プログラミング言語]]により異なる。 |
||
| 153行目: | 120行目: | ||
* 概念的には コードとデータが一つになっている。 |
* 概念的には コードとデータが一つになっている。 |
||
==== オブジェクトの実 |
==== オブジェクトという概念の実現のされ方 ==== |
||
実際のプログラムでは、全てのオブジェクトが互いに全く異なった存在ではなくオブジェクトは種類に分けることが出来る。 |
実際のプログラムでは、全てのオブジェクトが互いに全く異なった存在ではなくオブジェクトは種類に分けることが出来る。 |
||
| 160行目: | 127行目: | ||
このような場合、各オブジェクトがそれぞれメッセージ処理のコード（前述の「振る舞い」に当たる）を独自に備えていては無駄である。そこでオブジェクト指向プログラミング言語がオブジェクトを実現する際には多くの場合、内部的にはオブジェクトを2つの部分に分けている。 |
このような場合、各オブジェクトがそれぞれメッセージ処理のコード（前述の「振る舞い」に当たる）を独自に備えていては無駄である。そこでオブジェクト指向プログラミング言語がオブジェクトを実現する際には多くの場合、内部的にはオブジェクトを2つの部分に分けている。 |
||
===== 同一種類のオブジェクトの間で変わらない共通部分 ===== |
|||
一つは同一種類のオブジェクトに共有される部分、例えばメッセージ処理のコード（振る舞い）や定数（どのオブジェクトでも異ならないデータ）の類である。 |
|||
; 同一種類のオブジェクトの間で変わる個々の部分 |
|||
: もう一つは同一種類のオブジェクトでもそれぞれ異なる部分、典型的には各オブジェクトが保持するデータ群である。 |
|||
==== |
===== 同一種類のオブジェクトの間で変わる個々の部分 ===== |
||
もう一つは同一種類のオブジェクトでもそれぞれ異なる部分、典型的には各オブジェクトが保持するデータ群である。 |
|||
動的型付けを採用するオブジェクト指向言語の多くは、クラスより生成するインスタンスの他に[[メタクラス]]という機能を持ちクラス自体をオブジェクトとして扱うことが出来る。このためオブジェクトには、インスタンスオブジェクトとクラスオブジェクトという2種類のオブジェクトが存在する。Java等クラスオブジェクトを持たない言語の文化圏では、インスタンスオブジェクトとオブジェクトを混同して説明される事があるが、Objective-CやPython、Ruby等、インスタンスオブジェクトとクラスオブジェクトが別であるオブジェクト指向言語では区別して説明される。<ref>Objective-Cプログラミ |
|||
ング言語[https://developer.apple.com/jp/devcenter/ios/library/documentation/ObjC.pdf]</ref> |
|||
<ref>Classes ― Python v2.7.3 documentation[http://docs.python.org/2/tutorial/classes.html]</ref> |
|||
<ref>クラス／メソッドの定義 (Ruby manual) [http://www.ruby-lang.org/ja/old-man/html/_A5AFA5E9A5B9A1BFA5E1A5BDA5C3A5C9A4CEC4EAB5C1.html]</ref>元々はSmalltalkから始まった用語である。 |
|||
==== |
==== メッセージの処理のされ方 ==== |
||
{{seealso|this (プログラミング)}} |
{{seealso|this (プログラミング)}} |
||
そしてあるオブジェクトOにメッセージを配送し適切なメッセージ処理コード（振る舞い）を呼び出す際には、まず対象となるオブジェクトOについて共通部分の格納場所を見つけて適切なコードを選び出し、次にそのコードに対して処理対象となるオブジェクトO固有のデータの所在を示す'''オブジェクトID'''を渡すようになっている。 |
そしてあるオブジェクトOにメッセージを配送し適切なメッセージ処理コード（振る舞い）を呼び出す際には、まず対象となるオブジェクトOについて共通部分の格納場所を見つけて適切なコードを選び出し、次にそのコードに対して処理対象となるオブジェクトO固有のデータの所在を示す'''オブジェクトID'''を渡すようになっている。 |
||
| 179行目: | 141行目: | ||
また各オブジェクトの固有データから共通部分の格納場所を見つける方法もまた各言語により異なり、その言語の開発目的に応じて実に多種多様である。 |
また各オブジェクトの固有データから共通部分の格納場所を見つける方法もまた各言語により異なり、その言語の開発目的に応じて実に多種多様である。 |
||
==== JavaScriptの場合 ==== |
|||
例えば[[JavaScript]]の場合、各オブジェクトは[[連想配列]]であり、名前で表現されたメッセージのIDからメッセージ処理コードである関数への参照を直接見つけ出す。各オブジェクトの固有データもその連想配列に格納されていて、メッセージを処理する関数には連想配列のアドレスが渡される。 |
|||
; Selfの場合 |
|||
: [[Self]]のような[[プロトタイプベース|インスタンスベース]]のオブジェクト指向プログラミング言語では、プロトタイプとなるオブジェクトがメッセージを処理するコードも保持しており、オブジェクトがクローンされて作成されるときにそのプロトタイプのありかを示す情報もコピーされ、メッセージは受け取ったオブジェクトのIDを添えてプロトタイプに送られて処理される（Selfでは実行効率上の問題から後に内部的にクラスを作って利用するようになっている）。 |
|||
; クラスベースの言語の場合 |
|||
: 最も普及している[[クラスベース]]の言語では、共通部分はオブジェクトの種類を表現するクラスに保持され、各オブジェクトは固有データと共にそのクラスのIDを保持する。そしてオブジェクトに送られるメッセージはその送り先オブジェクトにあるクラスのIDからクラスを見つけ、その中からメッセージを処理するコードを見つけ出し、処理対象となっているオブジェクトのIDを付してそのコードを呼び出す仕組みになっている。 |
|||
==== |
==== Selfの場合 ==== |
||
[[Self]]のような[[プロトタイプベース|インスタンスベース]]のオブジェクト指向プログラミング言語では、プロトタイプとなるオブジェクトがメッセージを処理するコードも保持しており、オブジェクトがクローンされて作成されるときにそのプロトタイプのありかを示す情報もコピーされ、メッセージは受け取ったオブジェクトのIDを添えてプロトタイプに送られて処理される（Selfでは実行効率上の問題から後に内部的にクラスを作って利用するようになっている）。 |
|||
'''コンポジション'''は、複数のオブジェクトがある一つのオブジェクトの構成要素となっている巨大なオブジェクト群をいう。コンポジションのもとにあるオブジェクトは同一の生存期間を持ち、一つの巨大な仮想オブジェクトの構成部品として機能する。 |
|||
==== クラスベースの言語の場合 ==== |
|||
最も普及している[[クラスベース]]の言語では、共通部分はオブジェクトの種類を表現するクラスに保持され、各オブジェクトは固有データと共にそのクラスのIDを保持する。そしてオブジェクトに送られるメッセージはその送り先オブジェクトにあるクラスのIDからクラスを見つけ、その中からメッセージを処理するコードを見つけ出し、処理対象となっているオブジェクトのIDを付してそのコードを呼び出す仕組みになっている。 |
|||
=== メッセージ === |
=== メッセージ === |
||
| 207行目: | 168行目: | ||
=== クラス === |
=== クラス === |
||
{{main|クラス (コンピュータ)}} |
{{main|クラス (コンピュータ)}} |
||
'''クラス''' (class) は大多数のオブジェクト指向プログラミング言語で提供されている仕組みであり、上記の機能の殆ど全てに関わりがある。概念的にはクラスはオブジェクトの種類を表す。このためオブジェクトはクラスに'''属する'''という言い方をする。あるクラスに属するオブジェクトのことをそのクラスの'''インスタンス''' (instance) と呼ぶ。[[データ型]]の理論から見た場合クラスは型を定義する手段の一つである。クラスによってオブジェクトを記述する言語を'''[[クラスベース]]''' ({{Lang|en|class-based}}) のオブジェクト指向プログラミング言語と呼ぶ。 |
|||
==== クラスベース ==== |
|||
'''クラス''' (class) は大多数のオブジェクト指向プログラミング言語で提供されている仕組みであり、上記の機能のほとんど全てに関わりがある。概念的にはクラスはオブジェクトの種類を表す。このためオブジェクトはクラスに'''属する'''という言い方をする。あるクラスに属するオブジェクトのことをそのクラスの'''インスタンス''' (instance) と呼ぶ。[[データ型]]の理論から見た場合クラスは型を定義する手段の一つである。クラスによってオブジェクトを記述する言語を'''[[クラスベース]]''' ({{Lang|en|class-based}}) のオブジェクト指向プログラミング言語と呼ぶ。 |
|||
ハイブリッド型オブジェクト指向プログラミング言語では在来の[[データ型#レコード型|レコード型]]（Cでは[[構造体]]）の構文を拡張してクラスの定義を行うようにしたものが多い。 |
ハイブリッド型オブジェクト指向プログラミング言語では在来の[[データ型#レコード型|レコード型]]（Cでは[[構造体]]）の構文を拡張してクラスの定義を行うようにしたものが多い。 |
||
| 214行目: | 174行目: | ||
多くのオブジェクト指向プログラミング言語ではクラスを'''[[#データ・メンバ|データメンバ]]'''と'''[[#メソッド|メソッド]]'''の集まりとして記述する。平たく言えばデータ・メンバの集まりはオブジェクトが保持するデータの形式を定め、各メソッドはそれぞれオブジェクトが処理する特定のメッセージの処理方法を定める。しばしばデータ・メンバとメソッドには個別に[[オブジェクト指向プログラミング#アクセス権|アクセス権]]が設定できるようになっていて、そのクラスに属するオブジェクトが内部的に利用するものと他のクラスに属するオブジェクトに公開するものを分類できるようになっている。多くの場合、公開されたメソッドの集まりは全体として処理可能なメッセージのカタログの機能、即ち[[インタフェース (情報技術)|インタフェース]]を提供する。各言語によって異なるが特定の名前のメソッドを定めて、オブジェクトの生成や初期化時の処理、廃棄時の処理などを記述できるようにすることも多い。 |
多くのオブジェクト指向プログラミング言語ではクラスを'''[[#データ・メンバ|データメンバ]]'''と'''[[#メソッド|メソッド]]'''の集まりとして記述する。平たく言えばデータ・メンバの集まりはオブジェクトが保持するデータの形式を定め、各メソッドはそれぞれオブジェクトが処理する特定のメッセージの処理方法を定める。しばしばデータ・メンバとメソッドには個別に[[オブジェクト指向プログラミング#アクセス権|アクセス権]]が設定できるようになっていて、そのクラスに属するオブジェクトが内部的に利用するものと他のクラスに属するオブジェクトに公開するものを分類できるようになっている。多くの場合、公開されたメソッドの集まりは全体として処理可能なメッセージのカタログの機能、即ち[[インタフェース (情報技術)|インタフェース]]を提供する。各言語によって異なるが特定の名前のメソッドを定めて、オブジェクトの生成や初期化時の処理、廃棄時の処理などを記述できるようにすることも多い。 |
||
多くの言語でクラスは言語の要素として直接実現されているが、これは実行効率のためであり、そのように実現することが必須というわけではない。実際、各クラスをそれぞれオブジェクトとして提供する言語も存在する（例：[[Smalltalk]]）。このような言語ではある種の'''[[ |
多くの言語でクラスは言語の要素として直接実現されているが、これは実行効率のためであり、そのように実現することが必須というわけではない。実際、各クラスをそれぞれオブジェクトとして提供する言語も存在する（例：[[Smalltalk]]）。このような言語ではある種の'''[[リフレクション]]''' (reflection) が可能となる。即ち必要があればプログラムで実行時にクラスの動作を変更することが可能である。これは非常に大きな柔軟性を提供するが、[[処理系|言語処理系]]による最適化が難しいため実行効率は低下することが多い。近年では柔軟性と効率性を両立させるために基本的に言語要素としてクラスを提供した上で、リフレクション機能が必要なプログラムに対しては必要に応じて各クラスに対応するクラス・オブジェクトをプログラムが獲得できるようにしている言語が現れてきている。（例：JavaのリフレクションAPI） |
||
==== |
==== インスタンスベース ==== |
||
{{main|プロトタイプベース}} |
{{main|プロトタイプベース}} |
||
クラスは非常に多くのオブジェクト指向プログラミング言語で提供されている機能ではあるが、オブジェクト指向プログラミング言語に必須の機能というわけではない。実際にオブジェクトの管理や、データ・メンバや[[メソッド (計算機科学)|メソッド]]の記述、[[継承 (プログラミング)|継承]]に際してクラスという仕組みに依存せずに、もしくはクラスという仕組み自体を持たずに別の手段でこれらを実現している言語も存在する。このような言語を'''[[プロトタイプベース|インスタンスベース]]''' (''{{Lang|en|instance-based}}'')、'''オブジェクトベース''' (''object-based'') あるいは'''プロトタイプベース''' (''{{Lang|en|prototype-based}}'') のオブジェクト指向プログラミング言語と呼ぶ。インスタンスベースまたはそれに類するオブジェクト指向プログラミング言語には以下のようなものがある： |
クラスは非常に多くのオブジェクト指向プログラミング言語で提供されている機能ではあるが、オブジェクト指向プログラミング言語に必須の機能というわけではない。実際にオブジェクトの管理や、データ・メンバや[[メソッド (計算機科学)|メソッド]]の記述、[[継承 (プログラミング)|継承]]に際してクラスという仕組みに依存せずに、もしくはクラスという仕組み自体を持たずに別の手段でこれらを実現している言語も存在する。このような言語を'''[[プロトタイプベース|インスタンスベース]]''' (''{{Lang|en|instance-based}}'')、'''オブジェクトベース''' (''object-based'') あるいは'''プロトタイプベース''' (''{{Lang|en|prototype-based}}'') のオブジェクト指向プログラミング言語と呼ぶ。インスタンスベースまたはそれに類するのオブジェクト指向プログラミング言語には以下のようなものがある： |
||
*[[Self]] |
* [[Self]] |
||
*[[JavaScript]] |
* [[JavaScript]] |
||
*[[NewtonScript]] |
* [[NewtonScript]] |
||
*[[ドリトル (プログラミング言語)|ドリトル]] |
* [[ドリトル (プログラミング言語)|ドリトル]] |
||
* Squeak [[Etoys|eToys]]（[[Squeak]]の非開発者向けビジュアルスクリプト言語。SqueakToys とも） |
* Squeak [[Etoys|eToys]]（[[Squeak]]の非開発者向けビジュアルスクリプト言語。SqueakToys とも） |
||
| 250行目: | 210行目: | ||
ただし、Smalltalkのクラス変数はC++やJavaのクラス変数とは異なる。Smalltalkにおいて、C++やJavaのクラス変数と同等となる変数は'''プール辞書''' ({{Lang|en|pool dictionary}}) と呼ばれる。 |
ただし、Smalltalkのクラス変数はC++やJavaのクラス変数とは異なる。Smalltalkにおいて、C++やJavaのクラス変数と同等となる変数は'''プール辞書''' ({{Lang|en|pool dictionary}}) と呼ばれる。 |
||
=== インスタンスオブジェクトとクラスオブジェクト === |
|||
動的型付けを採用するオブジェクト指向言語の多くは、クラスより生成するインスタンスの他に[[メタクラス]]という機能を持ちクラス自体をオブジェクトとして扱うことが出来る。このためオブジェクトには、インスタンスオブジェクトとクラスオブジェクトという2種類のオブジェクトが存在する。Java等クラスオブジェクトを持たない言語の文化圏では、インスタンスオブジェクトとオブジェクトを混同して説明される事があるが、Objective-CやPython、Ruby等、インスタンスオブジェクトとクラスオブジェクトが別であるオブジェクト指向言語では区別して説明される。<ref>Objective-Cプログラミ |
|||
ング言語[https://developer.apple.com/jp/devcenter/ios/library/documentation/ObjC.pdf]</ref> |
|||
<ref>Classes ― Python v2.7.3 documentation[http://docs.python.org/2/tutorial/classes.html]</ref> |
|||
<ref>クラス／メソッドの定義 (Ruby manual) [http://www.ruby-lang.org/ja/old-man/html/_A5AFA5E9A5B9A1BFA5E1A5BDA5C3A5C9A4CEC4EAB5C1.html]</ref>元々はSmalltalkから始まった用語である。 |
|||
=== メソッド === |
=== メソッド === |
||
'''[[メソッド (計算機科学)|メソッド]]''' ({{Lang|en|method}}) は特定の種類のメッセージの処理方法を記述したものである。メソッドも[[メソッド (計算機科学)#インスタンスメソッド|インスタンス・メソッド]]と[[メソッド (計算機科学)#静的メソッド|クラス・メソッド]]の2種にできる。インスタンス・メソッドはそのクラスの各インスタンスオブジェクトを操作し、クラス・メソッドはクラスオブジェクトを操作する。メソッドとの集まりはそのクラスのオブジェクトが処理可能なメッセージのカタログの機能を果たす。 |
'''[[メソッド (計算機科学)|メソッド]]''' ({{Lang|en|method}}) は特定の種類のメッセージの処理方法を記述したものである。メソッドも[[メソッド (計算機科学)#インスタンスメソッド|インスタンス・メソッド]]と[[メソッド (計算機科学)#静的メソッド|クラス・メソッド]]の2種にできる。インスタンス・メソッドはそのクラスの各インスタンスオブジェクトを操作し、クラス・メソッドはクラスオブジェクトを操作する。メソッドとの集まりはそのクラスのオブジェクトが処理可能なメッセージのカタログの機能を果たす。 |
||
==== 他言語と比較したC++のメソッド ==== |
|||
一例として、[[C++]]では、メソッドは'''メンバ関数''' ({{Lang|en|member function}}) や'''関数メンバ''' (function member) と呼ばれる。これはC++が[[グローバル関数]]との区別をつけることと、クラスを[[抽象データ型]]の拡張と位置づけ、非メッセージメタファな言語思想を持っているためである。これら言語ではメソッドをオブジェクト（=クラスやインスタンス）の持ち物として捉えず、クラスに定義された機能要素であると考える。メッセージメタファを否定するため、同時にメッセージを実行するメソッド（手法）ではありえない。 |
|||
[[C++]]ではメソッドは'''メンバ関数''' ({{Lang|en|member function}}) や'''関数メンバ''' (function member) と呼ばれる。これはC++が[[グローバル関数]]との区別をつけることと、クラスを[[抽象データ型]]の拡張と位置づけ、非メッセージメタファな言語思想を持っている為である。これら言語ではメソッドをオブジェクト（=クラスやインスタンス）の持ち物として捉えず、クラスに定義された機能要素であると考える。メッセージメタファを否定するため、同時にメッセージを実行するメソッド（手法）ではありえない。 |
|||
==== クラスメソッド ==== |
==== クラスメソッドについて ==== |
||
[[メソッド (計算機科学)#静的メソッド|クラス・メソッド]]だが、オブジェクト指向の本義に立ち返れば、クラス・メソッドがあるということはクラスがメッセージをレシーブできるという事になる。 |
[[メソッド (計算機科学)#静的メソッド|クラス・メソッド]]だが、オブジェクト指向の本義に立ち返れば、クラス・メソッドがあるということはクラスがメッセージをレシーブできるという事になる。 |
||
| 267行目: | 234行目: | ||
[[Smalltalk]]ではクラスもオブジェクトの一種であるため当然クラスはメソッドをもつ。 |
[[Smalltalk]]ではクラスもオブジェクトの一種であるため当然クラスはメソッドをもつ。 |
||
===== クラスメソッドの呼び方について ===== |
|||
クラス・メソッドは、C++では'''静的メンバ関数''' ({{Lang|en|static member function}}) と呼ばれる。これはクラスがオブジェクトでない言語にとってはクラス・メソッドより正確な表現であり適切である。（"static" とはCの'''static変数'''に由来し'''auto変数'''の対語である。関数コールによりスタック上に生成される関数インスタンスに依存しない変数と、インスタンス生成有無にかかわらず実行できる関数の類似による。） |
クラス・メソッドは、C++では'''静的メンバ関数''' ({{Lang|en|static member function}}) と呼ばれる。これはクラスがオブジェクトでない言語にとってはクラス・メソッドより正確な表現であり適切である。（"static" とはCの'''static変数'''に由来し'''auto変数'''の対語である。関数コールによりスタック上に生成される関数インスタンスに依存しない変数と、インスタンス生成有無にかかわらず実行できる関数の類似による。） |
||
Javaではクラス・メソッドは'''静的メソッド''' ({{Lang|en|static method}}) とも呼ばれることもある。 |
Javaではクラス・メソッドは'''静的メソッド''' ({{Lang|en|static method}}) とも呼ばれることもある。 |
||
==== 特定の機能の割り当てについて ==== |
|||
==== システムメソッド ==== |
|||
言語によっては特定の名前のインスタンス・メソッドやクラス・メソッドにオブジェクトの生成、初期化、複製、廃棄といった機能を固定的に割り当てている。 |
言語によっては特定の名前のインスタンス・メソッドやクラス・メソッドにオブジェクトの生成、初期化、複製、廃棄といった機能を固定的に割り当てている。 |
||
===== 初期化と廃棄時に利用されるメソッド ===== |
|||
==== コンストラクタとデストラクタ ==== |
|||
初期化に利用されるメソッドを'''[[コンストラクタ]]'''あるいは'''構築子''' ({{Lang|en|constructor}})、廃棄時に利用されるメソッドを'''[[デストラクタ]]'''あるいは |
初期化に利用されるメソッドを'''[[コンストラクタ]]'''あるいは'''構築子''' ({{Lang|en|constructor}})、廃棄時に利用されるメソッドを'''[[デストラクタ]]'''あるいは'''消滅子''' ({{Lang|en|destructor}}) と呼んで特別に扱うことが多い。 |
||
構築子が初期化だけを担う場合はイニシャライザあるいは初期化子 ({{Lang|en|initializer}}) と呼ばれることもある。 |
|||
Javaは |
Javaでは消滅子を'''ファイナライザ''' ({{Lang|en|finalizer}}) と呼び、{{Javadoc:SE|name=Object#finalize()|java/lang|Object|finalize()}}メソッドがその役割を果たす。ただし、Javaにおけるファイナライザは本当に必要でない限り使用するべきではなく、C++などのデストラクタとは違った意味を持つ。 |
||
[[データ型]]の理論においては保持されるデータが必ずその型で認められる正しい値の範囲に収まることを保証するため、生成されるオブジェクトのデータ・メンバが必ず適切な |
[[データ型]]の理論においては保持されるデータが必ずその型で認められる正しい値の範囲に収まることを保証するため、生成されるオブジェクトのデータ・メンバが必ず適切な構築子によって初期化されるように求める。またオブジェクトが入出力機器や[[ファイル (コンピュータ)|ファイル]]や通信、[[プロセス]]や[[スレッド (コンピュータ)|スレッド]]、[[ウィンドウ]]と[[ウィジェット (GUI)|ウィジェット]]など[[ハードウェア]]や[[オペレーティングシステム]] (OS) が提供する資源を管理するために利用される場合に、構築子や消滅子でそれらの資源の使用開始（オープン処理）や使用終了（クローズ処理）をそれぞれ管理し、通常のメソッドでそれらにまつわる各種サービスを提供するようにすることで、それらのリソースがあたかもプログラム中のオブジェクトであるかのように自然に取り扱うことができるようになる。 |
||
C++ |
C++とJavaの場合、各クラスの名前がコンストラクタの名前として使用される。C++では一部のコンストラクタは[[型変換演算子]]として、また[[暗黙の型変換]]にも利用される。 |
||
=== |
=== アクセス権 === |
||
オブジェクト指向プログラミングにおいて、[[オブジェクト (プログラミング)|オブジェクト]]は、[[カプセル化]]されておりブラックボックスである。したがって、処理するメッセージのカタログ、つまりインターフェースだけが利用者に公開され、内部の詳細は隠されるのが基本である。しかし、あるクラスのインスタンスの内部だけで利用されるメソッドまで公開してしまうと、利用者にとって煩雑である。また、定数データ・メンバのようなものは一々メソッドでアクセスするようにせず公開してしまっても、カプセル化の利点は失われず効率的でもある。そこで、オブジェクトを定義するプログラマが各データ・メンバやメソッドについて公開・非公開を設定できる機能を用意している言語は多い。 |
|||
オブジェクト指向プログラミング言語では、オブジェクトへの[[参照 (情報工学)|参照]]や[[ポインタ (プログラミング)|ポインタ]]が多用される。そのため、オブジェクトの[[メモリ]]への割り当てと破棄に関して、[[ガベージコレクション]]による自動管理機能を備えているものが多い。ただし、すべての言語が備えているわけではない。例えば、C++はガベージコレクションを備えていない。 |
|||
=== アクセスコントロール === |
|||
オブジェクト指向プログラミングにおいて、[[オブジェクト (プログラミング)|オブジェクト]]は、[[カプセル化]]されておりブラックボックスである。したがって、処理するメッセージのカタログ、つまりインタフェースだけが利用者に公開され、内部の詳細は隠されるのが基本である。しかし、あるクラスのインスタンスの内部だけで利用されるメソッドまで公開してしまうと、利用者にとって煩雑である。また、定数データ・メンバのようなものは一々メソッドでアクセスするようにせず公開してしまっても、カプセル化の利点は失われず効率的でもある。そこで、オブジェクトを定義するプログラマが各データ・メンバやメソッドについて公開・非公開を設定できる機能を用意している言語は多い。 |
|||
例えば、Javaでは、データ・メンバやメソッドの宣言にpublicと指定すれば、他オブジェクトから自由に利用でき（'''公開'''と呼ばれる）、privateと指定すればオブジェクト内だけで利用できるようになる（'''非公開'''と呼ばれる）。 |
例えば、Javaでは、データ・メンバやメソッドの宣言にpublicと指定すれば、他オブジェクトから自由に利用でき（'''公開'''と呼ばれる）、privateと指定すればオブジェクト内だけで利用できるようになる（'''非公開'''と呼ばれる）。 |
||
| 298行目: | 261行目: | ||
なお、public、private、protectedというキーワードは、多くのプログラミング言語で用いられているが、その示す意味は言語ごとに差異があるため、注意が必要である。 |
なお、public、private、protectedというキーワードは、多くのプログラミング言語で用いられているが、その示す意味は言語ごとに差異があるため、注意が必要である。 |
||
=== コンポジション === |
|||
'''コンポジション'''は、複数のオブジェクトがある一つのオブジェクトの構成要素となっている巨大なオブジェクト群をいう。コンポジションのもとにあるオブジェクトは同一の生存期間を持ち、一つの巨大な仮想オブジェクトの構成部品として機能する。 |
|||
== 脚注 == |
== 脚注 == |
||
2018年8月28日 (火) 09:24時点における版
 | この記事には独自研究が含まれているおそれがあります。 |
オブジェクト指向プログラミング（オブジェクトしこうプログラミング、英: object-oriented programming, OOP）は、コンピュータ・プログラミングのパラダイム[1]のひとつで、オブジェクト指向の概念や手法を取り入れたものである。プログラムを、データとその振舞が結び付けられたオブジェクトの集まりとして構成する、などといった特徴がある。このパラダイムを指向しているプログラミング言語がオブジェクト指向プログラミング言語である。
特徴
オブジェクト指向プログラミングで用いられる代表的な概念および技法として、以下のものが挙げられる。
上記を含むオブジェクト指向プログラミングにおいて有用な機能（の一部）を言語仕様として備えたプログラミング言語を、オブジェクト指向プログラミング言語 (OOPL; object-oriented programming language) という。
ただし、上述の特徴はオブジェクト指向言語に固有の概念というわけではなく、非オブジェクト指向言語の中にもこの性質を備えるものもある。
背景
オブジェクト指向プログラミングという考え方が生まれた背景には、計算機の性能向上によって従来より大規模なソフトウェアが書かれるようになってきたということが挙げられる。大規模なソフトウェアが書かれコードも複雑化してゆくにつれ、ソフトウェア開発コストが上昇し、1960年代には「ソフトウェア危機 (software crisis)」といったようなことも危惧されるようになってきた。そこでソフトウェアの再利用、部品化といったようなことを意識した仕組みの開発や、ソフトウェア開発工程の体系化（ソフトウェア工学 (software engineering) の誕生）などが行われるようになった。
このような流れの中で、プログラムを構成するコードとデータのうちコードについては手続きや関数といった仕組みを基礎に整理され、その構成単位をブラックボックスとすることで再利用性を向上し、部品化を推進する仕組みが提唱され構造化プログラミング (structured programming) として1967年にエドガー・ダイクストラ (Edsger Wybe Dijkstra) らによってまとめあげられた（プログラミング言語の例としてはPascal 1971年）。なお、それに続けて「しかしデータについては相変わらず主記憶上の記憶場所に置かれている限られた種類の基本データ型の値という比較的低レベルの抽象化から抜け出せなかった。これはコードはそれ自身で意味的なまとまりを持つがデータはそれを処理するコードと組み合わせないと十分に意味が表現できないという性質があるためであった。」といったように、ほぼ間違いなく説明されている。
そこでデータを構造化し、ブラックボックス化するために考え出されたのが、データ形式の定義とそれを処理する手続きや関数をまとめて一個の構成単位とするという考え方でモジュール (module) と呼ばれる概念である（プログラミング言語の例としてはModula-2 1979年）。しかし定義とプログラム内の実体が一対一に対応する手続きや関数とは異なり、データはその形式の定義に対して値となる実体（インスタンスと呼ばれる）が複数存在し、各々様々な寿命を持つのが通例であるため、そのような複数の実体をうまく管理する枠組みも必要であることがわかってきた。そこで単なるモジュールではなく、それらのインスタンスを整理して管理する仕組み（例えばクラスとその継承など）まで考慮して生まれたのがオブジェクトという概念である（プログラミング言語の例としてはSimula 1962年）
Simulaのオブジェクトとクラスというアイデアは異なる二つの概念に継承される。一つはシステム全てをオブジェクトの集合と捉え、オブジェクトの相互作用をメッセージに喩えた「オブジェクト指向」である。オブジェクト間の相互作用をメッセージの送受と捉えることで、オブジェクトは受信したメッセージに見合った手続き単位（≒関数）を自身で起動すると考える。結果オブジェクトは自身の持つ手続きのカプセル化を行うことができ、メッセージが同じでもレシーバオブジェクトによって行われる手続きは異なる――多相性（ポリモーフィズム）を実現した（このメッセージを受け実行される手続き単位は、メッセージで依頼されたことを行うための「手法」の意味でメソッドと呼ばれる）。この思想に基づき作られたのがSmalltalk（1972年）であり、オブジェクト指向という言葉はこのとき作られた。
一方、Smalltalkとは別にSimulaの影響を受け作られたC++（1979年）は抽象データ型のスーパーセットとしてのクラス、オブジェクトに注目し、オブジェクト指向をカプセル化、継承、多相性をサポートするものと再定義した（その際、実行時速度重視及びコンパイラ設計上の制約により、変数メタファである動的束縛の特徴は除外された）。これらは当初抽象データ型、派生、仮想関数と呼ばれ、オブジェクトのメンバ関数を実体ではなくポインタとすることで、継承関係にあるクラスのメンバ関数のオーバーライド（上書き）を可能にしたことで、多相性を実現した（この流儀ではメッセージメタファはオブジェクト指向に必須ではないものと定義し、オブジェクトの持つ手続きをメソッドとは呼ばずメンバ関数と呼ぶ）。この他、Smalltalkにある動的束縛の類似的な機能としてオーバーロード（多重定義）が実装されている。
Smalltalkはこの「全てをオブジェクトとその相互作用で表現する」というデザインに立ち設計されたため、全てをファイルと捉えるファイル指向オペレーティングシステムからの脱却と、プログラムをフロー制御された手続きと捉える手続き型言語からの脱却が行われた。そのためSmalltalkは自身がオブジェクト指向オペレーティングシステムでもあること、メッセージ・パッシングなどの特徴を持った。これは当時のプログラム言語としては特異的であり、ガベージコレクタを必要としインタプリタ形式で実行される処理の重さも手伝って先進的ではありながら普及しがたいものであると捉えられた。また、メッセージでの多相性は、変数へのオブジェクトの動的束縛が前提となるため、静的型チェックが必要な実行時性能重視のコンパイラ言語にとって、実装から除外すべき特徴となった。
C++の創始者ビャーネ・ストロヴストルップは、Smalltalkのような論理美の追求よりも、現用としての実用性を重視した。そのため、C++の再定義した「オブジェクト指向」はこれらの問題を全てクリアにし、既存言語の拡張としてオブジェクト指向機能を実装できることでブレイクスルーを迎え急速に普及する。これによりメッセージ送信という考え方はやや軽視されるようになり、オブジェクト指向とはC++の再定義したものと広く認知されるようになった。
1980年代後半に次々と生まれたオブジェクト指向分析・設計論は、Smalltalkを源流とするオブジェクト指向を基に組み立てられた。このときSmalltalkは健在であったが広く普及しているとは言えずC++で実装する機会が多かったが、C++はSmalltalkとは思想的にやや異なることと、仕様の複雑さが問題とされた。このニーズを受けC++の提示した現実解と、Smalltalk的理想論を融合するものとして、構文面ではシンプル化しながらも強くC++の影響を受けつつ、一方で用語や思想面でSmalltalk色を濃くした[要出典]Java（1991年）が作られた。バランス感覚に長けたJavaの登場によってオブジェクト指向開発に必要な要素が全てそろい、1990年代後半からオブジェクト指向は広く普及するようになった。
オブジェクト指向プログラミング言語一覧
オブジェクト指向プログラミングをサポートする機能を備える代表的なプログラミング言語（オブジェクト指向プログラミング言語）としては以下のようなものが挙げられる：
- Simula 1962年
- オブジェクトとクラスを導入した最初の言語。また、C++が再定義したオブジェクト指向プログラミング言語の要件を満たすことから、最初のオブジェクト指向プログラミング言語とされることもある。クラスベース。当初はシミュレーション記述用に開発されたものであったが、後に汎用化された。
- Smalltalk 1972年
- オブジェクト間の相互作用にメッセージという機構を導入した最初の言語。オブジェクト指向と言う言葉は、Smalltalkのプログラミングスタイルを説明するために作られた。動的な型付けにより高い柔軟性を持つ。
- C++ 1979年
- C言語のオブジェクト指向拡張。Simula言語風にクラスを定義でき、C言語の型システムを強化している。当初はC言語に対して上位互換であった。また、強い型付けによりC言語譲りの実行効率の高いコードが生成できる。
- Objective-C 1983年
- C言語のオブジェクト指向拡張。C言語のコードとSmalltalk型のオブジェクトシステムを混在させたもの。オブジェクトシステム自体はCで書かれたランタイム。
- Eiffel 1986年
- 強い型付けを行う型システムや表明など堅牢性を強く意識して設計されたオブジェクト指向プログラミング言語。C++にテンプレートが導入される前に総称型を導入していた。
- Self 1987年
- 最初のインスタンスベースのオブジェクト指向プログラミング言語。
- CLOS 1988年
- 関数型言語Common Lispのオブジェクト指向仕様。
- Modula-3 1988年
- モジュールを実現していたModula-2言語のオブジェクト指向拡張。
- Python 1990年
- 最初のオブジェクト指向スクリプト言語。
- Sather 1990年
- Eiffelを拡張したもの。実行効率面での工夫が見られる。
- NewtonScript 1993年
- PDA環境用に修正されたSelf言語。PDAの性質を生かすため永続オブジェクトをサポートしている。
- Ruby 1993年
- オブジェクト指向スクリプト言語。クラスのMix-inなどのユニークな機能を持つほか、正規表現に渡るまで全てがクラスとして実装されていることが特徴。
- Perl 1994年
- Perl 5.0にてオブジェクト指向に対応。既存のPerl言語に後付けで拡張されたため記法は特殊だが、機能面では他のオブジェクト指向言語に引けを取らない。
- Adaのオブジェクト指向拡張 1995年
- 恐らく最も仕様が複雑なオブジェクト指向プログラミング言語。
- Java 1995年
- 仮想マシン（Java仮想マシン）上で動作することによる高い可搬性、リフレクションやスレッドの標準サポートと充実したライブラリ群で知られているオブジェクト指向プログラミング言語。
- Object Pascal (Delphi) 1995年
- Pascal言語のオブジェクト指向拡張。
- JavaScript 1996年
- ウェブページ上で実行することを主目的に開発されたスクリプト言語。プロトタイプベースの言語である。
- OCaml 1996年
- 関数型言語MLのオブジェクト指向拡張。クラスが型推論機構に組み込まれているという特徴がある。
- PHP 2000年
- 動的にWebページを生成することを主目的としたスクリプト言語。バージョン4からオブジェクト指向に対応し、バージョン5でアクセス権やインターフェースなど、オブジェクト指向の強化が行われている。
- C# 2000年
- Javaとよく似た作りでJavaと同じく仮想マシン上で動作するが様々な部分で拡張されている。.NET Framework上で動く。
- Visual Basic.NET 2002年
- 既存のVisual Basic（6.0以前）を大きく改訂してオブジェクト指向に対応。C＃同様.NET Framework上で動く。
- COBOL 2002年
- 2002年に制定された国際規格に、オブジェクト指向機能が採用された。1994年には、国際規格案を先取りした商用コンパイラ上で利用可能になった。オブジェクト指向構文を使わないCOBOLプログラムと混在できる。
- Ceylon 2011年
- Java をもとにつくられ、Java のもつ長所と短所を考慮しつつ、商用言語として再設計された言語。
- Swift 2014年
- Objective-Cのオブジェクトを引き継ぎながらも、ベースのC言語を取り除いて新しく再設計された言語。
また、以下のような分類もある。
- ハイブリッド型オブジェクト指向プログラミング言語 (hybrid object-oriented language)
- 「ハイブリッド」という用語をどう定義するかによるが、たとえば「手続き型や関数型などの既存の他のパラダイムを主とした言語に、オブジェクト指向機能を拡張した」という言語を「ハイブリッドだ」、と言う者もいれば、「当初からオブジェクト指向を含む、複数のパラダイムを指向する言語として設計された」という言語を「ハイブリッドだ」と言う者もいる。例としては、以上のどちらの基準か、それとも別の定義によるものかは知らないが、OCaml、C++およびObjective-C、CLOS、Object Pascal、object-oriented COBOLなどを挙げる者がいる。
- 純粋なオブジェクト指向プログラミング言語 (pure object-oriented language)
- 「純粋」という用語をどう定義するかによるが、たとえばSmalltalkやRubyのように「あらゆる対象がオブジェクトである」という言語（たとえば、Rubyではnilも、ヌルポインタのようなものではなく、NilClassのインスタンスというオブジェクトである。この場合対照例としては、通常の数値型などがオブジェクトでないJavaであろう）を「純粋だ」と言う者もいれば、「当初からオブジェクト指向プログラミング言語として設計された」言語を「純粋だ」と言う者もいる（こちらの定義ではJavaも含まれるだろうか）。例としては、以上のどちらの基準か、それとも別の定義によるものかは知らないが、Smalltalk、Eiffel、Self、Ruby、Swiftなどを挙げる者がいる。
オブジェクト指向プログラミング言語では、オブジェクトへの参照やポインタが多用される。そのため、オブジェクトのメモリへの割り当てに関して、自動ガベージコレクション機能を備えているものが多い。ただし、すべての言語が備えているわけではない。例えば、C++はガベージコレクションを備えていない。
オブジェクト指向の応用
プログラミング（ただし、ごく狭義の。普通は以下のようなものもプログラミングの工程に含まれる）にとどまらず、以下のようなより広い範囲にオブジェクト指向は応用されている。
また、当初はJavaないしC++におけるデザインパターンを表記・記述するための（図形を含む）言語として設計が始まった統一モデリング言語は、ツールベンダ等の意向により以上のような応用をサポートするためのものとして、仕様は大幅に膨れている。
オブジェクト指向プログラミング言語の仕組み
オブジェクト指向プログラミング言語は、相互にメッセージを送りあうオブジェクトの集まりとしてプログラムを構成することができる仕組みを持つ。 そのために、少なくともオブジェクトについての3つの仕組みと、オブジェクトの管理についての3つの仕組みが必要となる。
- オブジェクトの仕組み
-
- オブジェクトに蓄えられる情報、データを表現する仕組み。
- 他のオブジェクトにメッセージを配送する仕組み。
- 受け入れ可能な各種メッセージに対応して、処理する事柄を記述する仕組み（メソッド）。
- オブジェクトを管理する仕組み
-
- オブジェクト間の関係を整理分類して系統立てる仕組み。
- 必要なオブジェクトを作成・準備する仕組み。
- 不要なオブジェクトを安全に破棄する仕組み。
これらをどのように言語の要素として提供し、どのような機械語コードで実現するかによって様々なオブジェクト指向プログラミング言語のバリエーションが生まれる。以下、オブジェクト指向プログラミング言語が提供する様々な要素が上記の仕組みをどのように実現しているかについて概観する。
オブジェクトの概念と実際
オブジェクト (object) はオブジェクト指向プログラミングの中心となる概念であり、この概念を実際にどう実現するかはオブジェクト指向プログラミング言語により異なる。
以下、概念と実際がどう対応しているかについて説明する。
- 概念的には各々のオブジェクトは、プログラムが表現する情報システムの中で能動的な役割を持った存在を表現している。
- 概念的には メッセージを受け取り、その処理の過程で内部に蓄えたデータを書き換え、必要に応じて他のオブジェクトにメッセージを送るといった動作をしている。
- 概念的には コードとデータが一つになっている。
オブジェクトという概念の実現のされ方
実際のプログラムでは、全てのオブジェクトが互いに全く異なった存在ではなくオブジェクトは種類に分けることが出来る。
例えば勤怠管理のシステムであれば、氏名や年齢、累積勤務時間などのデータは異なっても社員は皆、出勤し退勤するという処理（振る舞い）は同じだろう。このように複数の異なるオブジェクトが同じ種類のメッセージを受け取り共通の処理をするのが普通である。
このような場合、各オブジェクトがそれぞれメッセージ処理のコード（前述の「振る舞い」に当たる）を独自に備えていては無駄である。そこでオブジェクト指向プログラミング言語がオブジェクトを実現する際には多くの場合、内部的にはオブジェクトを2つの部分に分けている。
同一種類のオブジェクトの間で変わらない共通部分
一つは同一種類のオブジェクトに共有される部分、例えばメッセージ処理のコード（振る舞い）や定数（どのオブジェクトでも異ならないデータ）の類である。
同一種類のオブジェクトの間で変わる個々の部分
もう一つは同一種類のオブジェクトでもそれぞれ異なる部分、典型的には各オブジェクトが保持するデータ群である。
メッセージの処理のされ方
そしてあるオブジェクトOにメッセージを配送し適切なメッセージ処理コード（振る舞い）を呼び出す際には、まず対象となるオブジェクトOについて共通部分の格納場所を見つけて適切なコードを選び出し、次にそのコードに対して処理対象となるオブジェクトO固有のデータの所在を示すオブジェクトIDを渡すようになっている。
各オブジェクトの固有データを識別するオブジェクトIDを表現する方法も様々で、オブジェクトのIDとしては名前、番号なども用いられることがあるが、オブジェクトの固有データを記憶している主記憶上のアドレスがそのまま用いられることもある。アドレスを直接利用することは非常に実行効率の向上に寄与するが、プログラム間でのオブジェクトの受け渡し、セッション間（プログラムが終了して再度起動された時など）でのオブジェクトの受け渡しにはそのまま利用することができない。
また各オブジェクトの固有データから共通部分の格納場所を見つける方法もまた各言語により異なり、その言語の開発目的に応じて実に多種多様である。
JavaScriptの場合
例えばJavaScriptの場合、各オブジェクトは連想配列であり、名前で表現されたメッセージのIDからメッセージ処理コードである関数への参照を直接見つけ出す。各オブジェクトの固有データもその連想配列に格納されていて、メッセージを処理する関数には連想配列のアドレスが渡される。
Selfの場合
Selfのようなインスタンスベースのオブジェクト指向プログラミング言語では、プロトタイプとなるオブジェクトがメッセージを処理するコードも保持しており、オブジェクトがクローンされて作成されるときにそのプロトタイプのありかを示す情報もコピーされ、メッセージは受け取ったオブジェクトのIDを添えてプロトタイプに送られて処理される（Selfでは実行効率上の問題から後に内部的にクラスを作って利用するようになっている）。
クラスベースの言語の場合
最も普及しているクラスベースの言語では、共通部分はオブジェクトの種類を表現するクラスに保持され、各オブジェクトは固有データと共にそのクラスのIDを保持する。そしてオブジェクトに送られるメッセージはその送り先オブジェクトにあるクラスのIDからクラスを見つけ、その中からメッセージを処理するコードを見つけ出し、処理対象となっているオブジェクトのIDを付してそのコードを呼び出す仕組みになっている。
メッセージ
メッセージ (message) はオブジェクト間の通信でやりとりされる情報である。メッセージはメッセージ種別を示すIDとメッセージの種別に応じた追加の情報からなる定まった形式を持つ。追加の情報はそれ自身が何らかのオブジェクトやオブジェクトのIDである場合もある。メッセージの配送には大別して2つの方式がある：
- 同期式
- オブジェクトがメッセージの送信を依頼すると相手が受信、処理して結果を返すまでそのオブジェクトは処理を中断して待つ。
- 非同期式
- オブジェクトがメッセージの送信を依頼した後、相手の応答を待たずにオブジェクトは処理を続行する。処理結果は別のメッセージとして返される。
両者とも一長一短がありどちらがすぐれているとは言えない。また並列・並行処理が可能な環境では一方の仕組みがあれば、それを利用してもう一方も実現可能である。一般的な傾向としては、メッセージの伝送や処理に時間が掛かる場合は非同期式の方が効率は良く、そうでない場合には同期式の方が挙動が分かりやすく利用しやすい。
並列処理・並行処理システムを記述する言語や分散システムを記述する言語ではOSなどが提供するメッセージ機能や自前の配送メカニズムを使って非同期式でメッセージが配送される場合もあるが、一般にオブジェクト指向プログラミング言語ではその多くが同一のプログラム内の通信であるので同期式のメッセージ配送が利用される。特にコンパイルされるタイプのオブジェクト指向プログラミング言語では、しばしば特別なメッセージ配送の仕組みを用意せず、特別な形式の関数の呼び出しでメッセージの配送を直接に表現する。即ち、各メソッドを内部的には関数として実現し、メッセージIDはメソッド名で表し、関数の第一引数としてオブジェクトIDを渡し（この第一引数は多くの言語で特別な記法で表される）、追加の引数としてメッセージの追加部分の情報を渡すのである。こうするとメッセージ送信は直接的なメソッドの関数呼び出しとして表せる。ただし、プログラムで継承の仕組みが利用されている場合はプログラムのテキストからだけでは呼び出すべきメソッドが決定できない場合があるので、実行時にメソッドを決定するためにメソッド・サーチや仮想関数テーブルといった仕組みが必要となる。
多くのプログラミング言語においてメッセージは、メソッド呼び出しの比喩でしかないことが多い。SmalltalkやObjective-Cの様な言語では、メッセージはメソッド呼び出しとは独立した機構として存在している。メッセージが機構として存在する言語では、メッセージをオブジェクトに送信した際、宛先のオブジェクトにメッセージで指定したメソッドが存在しない場合でもメッセージを処理することが出来る。これを利用し、メッセージの配送先を別のオブジェクトに指定したり、メッセージを一時保存したり、不要なメッセージを無視する等といったメッセージ処理が行われる。
クラス
クラス (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) と呼ばれる。
インスタンスオブジェクトとクラスオブジェクト
動的型付けを採用するオブジェクト指向言語の多くは、クラスより生成するインスタンスの他にメタクラスという機能を持ちクラス自体をオブジェクトとして扱うことが出来る。このためオブジェクトには、インスタンスオブジェクトとクラスオブジェクトという2種類のオブジェクトが存在する。Java等クラスオブジェクトを持たない言語の文化圏では、インスタンスオブジェクトとオブジェクトを混同して説明される事があるが、Objective-CやPython、Ruby等、インスタンスオブジェクトとクラスオブジェクトが別であるオブジェクト指向言語では区別して説明される。[2] [3] [4]元々はSmalltalkから始まった用語である。
メソッド
メソッド (method) は特定の種類のメッセージの処理方法を記述したものである。メソッドもインスタンス・メソッドとクラス・メソッドの2種にできる。インスタンス・メソッドはそのクラスの各インスタンスオブジェクトを操作し、クラス・メソッドはクラスオブジェクトを操作する。メソッドとの集まりはそのクラスのオブジェクトが処理可能なメッセージのカタログの機能を果たす。
他言語と比較したC++のメソッド
C++ではメソッドはメンバ関数 (member function) や関数メンバ (function member) と呼ばれる。これはC++がグローバル関数との区別をつけることと、クラスを抽象データ型の拡張と位置づけ、非メッセージメタファな言語思想を持っている為である。これら言語ではメソッドをオブジェクト（=クラスやインスタンス）の持ち物として捉えず、クラスに定義された機能要素であると考える。メッセージメタファを否定するため、同時にメッセージを実行するメソッド（手法）ではありえない。
クラスメソッドについて
クラス・メソッドだが、オブジェクト指向の本義に立ち返れば、クラス・メソッドがあるということはクラスがメッセージをレシーブできるという事になる。
クラスがメソッドを持つことは便利だが、クラスをオブジェクトとすると実行効率に劣るため、双方の利点を享受できるこのような折中的仕様を取る言語は多い。
C++ではクラスはオブジェクトでは無いが、一方でクラスに属するメソッドは存在する。
Eiffelではクラスはオブジェクトでは無いためクラスのメソッドであるクラス・メソッドは存在しない。
Smalltalkではクラスもオブジェクトの一種であるため当然クラスはメソッドをもつ。
クラスメソッドの呼び方について
クラス・メソッドは、C++では静的メンバ関数 (static member function) と呼ばれる。これはクラスがオブジェクトでない言語にとってはクラス・メソッドより正確な表現であり適切である。（"static" とはCのstatic変数に由来しauto変数の対語である。関数コールによりスタック上に生成される関数インスタンスに依存しない変数と、インスタンス生成有無にかかわらず実行できる関数の類似による。）
Javaではクラス・メソッドは静的メソッド (static method) とも呼ばれることもある。
特定の機能の割り当てについて
言語によっては特定の名前のインスタンス・メソッドやクラス・メソッドにオブジェクトの生成、初期化、複製、廃棄といった機能を固定的に割り当てている。
初期化と廃棄時に利用されるメソッド
初期化に利用されるメソッドをコンストラクタあるいは構築子 (constructor)、廃棄時に利用されるメソッドをデストラクタあるいは消滅子 (destructor) と呼んで特別に扱うことが多い。
構築子が初期化だけを担う場合はイニシャライザあるいは初期化子 (initializer) と呼ばれることもある。
Javaでは消滅子をファイナライザ (finalizer) と呼び、Object#finalize()メソッドがその役割を果たす。ただし、Javaにおけるファイナライザは本当に必要でない限り使用するべきではなく、C++などのデストラクタとは違った意味を持つ。
データ型の理論においては保持されるデータが必ずその型で認められる正しい値の範囲に収まることを保証するため、生成されるオブジェクトのデータ・メンバが必ず適切な構築子によって初期化されるように求める。またオブジェクトが入出力機器やファイルや通信、プロセスやスレッド、ウィンドウとウィジェットなどハードウェアやオペレーティングシステム (OS) が提供する資源を管理するために利用される場合に、構築子や消滅子でそれらの資源の使用開始（オープン処理）や使用終了（クローズ処理）をそれぞれ管理し、通常のメソッドでそれらにまつわる各種サービスを提供するようにすることで、それらのリソースがあたかもプログラム中のオブジェクトであるかのように自然に取り扱うことができるようになる。
C++とJavaの場合、各クラスの名前がコンストラクタの名前として使用される。C++では一部のコンストラクタは型変換演算子として、また暗黙の型変換にも利用される。
アクセス権
オブジェクト指向プログラミングにおいて、オブジェクトは、カプセル化されておりブラックボックスである。したがって、処理するメッセージのカタログ、つまりインターフェースだけが利用者に公開され、内部の詳細は隠されるのが基本である。しかし、あるクラスのインスタンスの内部だけで利用されるメソッドまで公開してしまうと、利用者にとって煩雑である。また、定数データ・メンバのようなものは一々メソッドでアクセスするようにせず公開してしまっても、カプセル化の利点は失われず効率的でもある。そこで、オブジェクトを定義するプログラマが各データ・メンバやメソッドについて公開・非公開を設定できる機能を用意している言語は多い。
例えば、Javaでは、データ・メンバやメソッドの宣言にpublicと指定すれば、他オブジェクトから自由に利用でき（公開と呼ばれる）、privateと指定すればオブジェクト内だけで利用できるようになる（非公開と呼ばれる）。
しかし、ある機能を提供するのに、一個ではなく一群のクラスに属するオブジェクトでそれを記述するのが相応しい事例がある。そのような場合、関係する一群のオブジェクト間でだけデータ・メンバやメソッドを利用できれば便利である。それを可能にするための拡張がいくつか存在する。例えば、継承を利用しているときに、あるクラスが子孫にだけ利用を許可したいデータ・メンバやメソッドがある場合、Javaではprotectedを指定することでそれを実現できる（限定公開と呼ばれる）。また、ある一群の機能を実現するクラスのライブラリで、その実現に関連するクラスに属するオブジェクトだけがデータ・メンバやメソッド利用できるようにしたい場合も考えられる。また、Javaでは、ライブラリを構成するクラス群を表現するパッケージ (package) という仕組みがあり、特に指定がない場合は同一パッケージに属するクラスのオブジェクト間でのみデータ・メンバやメソッドを相互に利用可能である。その他にも、デザインパターンの一つであるFacade パターンでは、この仕組みがテクニックとして応用されている。また、C++ではフレンド宣言という仕組みがあり、あるクラスで外部非公開に指定されているデータ・メンバやメソッドについて、その利用を許可するクラスや関数のリストをクラス内に列挙することができる。
なお、public、private、protectedというキーワードは、多くのプログラミング言語で用いられているが、その示す意味は言語ごとに差異があるため、注意が必要である。
コンポジション
コンポジションは、複数のオブジェクトがある一つのオブジェクトの構成要素となっている巨大なオブジェクト群をいう。コンポジションのもとにあるオブジェクトは同一の生存期間を持ち、一つの巨大な仮想オブジェクトの構成部品として機能する。
