「オブジェクト指向プログラミング」の版間の差分

[[ファイル:History of object-oriented programming languages.svg|サムネイル|OOP言語の系譜（水色がOOP）|代替文=|280x280ピクセル|リンク=Special:FilePath/History_of_object-oriented_programming_languages.svg]]

OOPの成り立ちにもまた諸説ある。オブジェクト指向プログラミングという言葉自体は、計算機科学者[[アラン・ケイ]]が1972年から80年にかけて公開した[[Smalltalk]]の言語設計を説明する中で初めて生み出されている。なお、データとコードの複合体である[[オブジェクト (プログラミング)|オブジェクト]]という用語を確立したのは1967年公開の[[Simula|Simula67]]であった。[[Simula|Simula67]]の[[クラス (コンピュータ)|クラス]]と[[オブジェクト (プログラミング)|オブジェクト]]の設計及び用法は[[手続き型プログラミング]]の機能拡張に近いものであったが、こちらもOOPの草分けと見なされるようになった。[[Smalltalk]]のプログラム内のあらゆる要素をオブジェクトとして扱い、[[メッセージパッシング]]で相互作用させる本来の意味でのオブジェクト指向設計は、哲学的かつ理論偏重のきらいがあったので実践面ではさほど広まらなかった。1983年に公開された[[C++]]が契機となり、OOPはまた違った角度から注目されるようになった。最終的にこの[[C++]]の設計スタイルが物議を醸しながらもOOPの主流となるに到り、同時にOOPの三大原則とされる[[カプセル化]]、[[継承 (プログラミング)|継承]]、[[ポリモーフィズム|多態性]]の[[プログラミングパラダイム]]が確立されている。

プログラミングパラダイムとしてのオブジェクト指向の確立は紆余曲折を経ており（後述）その詳細の解釈も様々であるが、一定の枠組みとなる三つの原則仕様（''fundamental principle''）が存在する。この三原則に従った言語仕様を総体的または部分的に備えたプログラミング言語がオブジェクト指向準拠と判別される。1～3はいわゆるOOPの三大原則とされるものであり、[[C++]]を契機にして確立提唱された。4はオブジェクト指向プログラミングという用語の発端となった[[Smalltalk]]設計の主軸であるが、現在では亜流となっている。

従来のプログラミング環境でムは、動作を定義表現するコード（関数）が、状態を表現するデータ（変数）を扱う操作する形でプログラムを記述すされるのが一般的だったが、開発規模の拡大に伴い解決の難しいソフトウェア・バグ原因の大半は、データの予期せぬ変動と各データ間の不整合である事が経験則で知られるようになって来た。そこでデータを中心にしてプログラムを組み立てようとする考え方が生まれ、その目的に沿うものとしてデータとコードの複合体であるオブジェクトに白羽の矢が立てられた。オブジェクト内のデータは基本的に同じオブジェクト内のコードだけが参照または変動可能とする仕組みが考案され、これがカプセル化と呼ばれた。データを変動させたコード位置の把握を容易にする為に、各データにアクセス出来るコードの範囲を厳密に定めたカプセル化の機能は、範囲外アクセスをコンパイルレベルで禁止して想定外のデータ変動をもたらす人的ミスを減らした。また、データを変動させるコードを呼び出すそのまたコード位置の把握も芋蔓式に必要となったので、コードにもアクセス許可能範囲が定められる様になり、た。更にアクセス範囲の広さにも段階が設つけられたので、特定の外部をも含んだ柔軟な内部隠蔽の設計定が可能となった。

プログラム内の膨大な数のデータは通常グループ化（構造体）されて扱われていたが、複数の構造体間にまたがる共通のデータ集合が数多く目に付くようになり、その冗長さと整合性の問題が浮き彫りとなっていた。これを解決する為に構造体＝オブジェクトを複数の'''階層要素'''に分け、共通のデータ集合を親階層とし、派生する子階層に親階層の参照アドレスを持たせて連結する構造が考案された。A階層から成る親オブジェクトから派生した子オブジェクトはA＋B階層として構成され、これが継承と呼ばれた。コードから参照されたデータがB階層に無い時は、次のA階層に有るか探す仕組みとなり、この連鎖によって傍からは一つのオブジェクトとして存在した。なおデータと同様に共通のメソッド集合も親階層にまとめられた。その応用として後述の仮想関数と同義である抽象メソッド集合だけの階層を独立させたインターフェースまたは純粋抽象クラスがあり、これを親階層として継承（実装）する行為は'''[[派生型|サブタイピング]]'''（''subtyping''）となった。サブタイピングは後述の多態性のメカニズムの一つでもある。なお、継承クラスで任意の機能を追加出来る継承は従来コードの再利用性を高めるとも考えられたが、深い継承がもたらす構成把握の難化が問題視されてほぼ否定された。これ継承による再利用性はクラスライブラリの使用内に留まっている。{{いつ範囲|date=2019年2月|現在}}では深い継承は倦厭される様になり、代わりに仮想メソッドテーブル（Javaの''interface''など）を実装させる横に長い継承が重視されている。また、クラスのメカニズムをベースとするOOP言語現状では多態性を実現する為の手段として用いられていある。

サブタイプ多態性は動的なものである。最も初期のOOPであるSimula67は、シミュレーション内で扱う多種多様なオブジェクトを継承によって体系化したが、コード部分の細かな違いは共通スーパークラスに属する共通プロシージャ内の分岐フローで処理していた。サブクラスの数だけ分岐構文が増える頻雑さを解消する為に、共通プロシージャをただの住所テーブルにしてサブクラスの実装時に同名プロシージャのアドレスを収納させ、共通プロシージャ呼び出し時はにそのアドレスへジャンプするという機能が考案された。住所テーブルと化した共通プロシージャは仮想的存在と見なされたので、これがの機能は'''仮想関数'''となっ呼ばれた。'''動的ディスパッチ'''はSmalltalkのオブジェクト設計に由来するものであり、その実装の仕方は様々でやや曖昧な仕様でもある。メッセージを受け取ったレシーバーがオブジェクト内部で動的な状態に従い動的な処理を行って結果を返すというランタイム環境上のプロセスが後に動的ディスパッチのカテゴリで括られた。遠隔プロセスを扱うリモ[[分散コンピューティング]]を表現する[[Object Request Broker|オブジェクトメ間通信]]とそれに基づく[[ソッドのシステムフトウェアコンポーネント]]も動的ディスパッチに該当するものである。仮想関数および動的ディスパッチと同義に扱われる用語に'''[[動的束縛|遅延バインディング]]'''（''late binding''）があるが、これはより幅広い意味を含みOOP外でも用いられる言葉である。'''多重ディスパッチ'''は動的な関数オーバーロードに近いものである。関数コール時または関数ブロック内で、それぞれの引数が動的に型審査されて型変化（''dynamic casting''）された後に、その引数パターンに対応した同名関数または分岐ルーチンに処理が移行されるという動的変化プロセスを指した。'''ダブルディスパッチ'''は多重ディスパッチの亜流またはその派生物的存在であり、二通りの考え方がある。動的型審査および型変化されるBオブジェクトを単一引数にしてAオブジェクトの仮想関数メソッドを呼び出す形態と、多重ディスパッチに用いる引数を二つに限定した形態である。いずれも実行時状態に応じた動的変化プロセスとなった。これは主にデータ集合を対象にして分類、解析、作用といった処理を連続的または再帰的に行うアルゴリズムで用いられた。

Smalltalkの影響を受けた後継言語においても、あらゆるプログラム要素をメッセージで表現しようとする理論の追求は避けられ、例えば制御フローは制御構文で扱われている。またメッセージングに対する認識もシフトし、オブジェクトの代表となるメソッドがパラメータを受け取り多様な処理と移譲を行ういわゆるレシーバーの仕組み自体がメッセージングそのものと見なされるようになった。そのメカニズムを応用したリモー[[Object Request Broker|オブジェクトメソッド間通信]]を実現するバイトデータの送受信もメッセージパッシングの代表例となった。また、オブジェクトのメソッドコールもメッセージと定義する見解も出たが、これは同時に物議を醸している。この様にメッセージパッシング設計の本質は見失われながらも、その側面的仕様は数々のOOP言語に導入されてもいる。