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

オブジェクト指向プログラミング（オブジェクトしこうプログラミング、英: object-oriented programming、略語:OOP）とは、互いに密接な関連性を持つデータ（変数またはプロパティ）とコード（関数またはメソッド）をひとつにまとめてオブジェクトとし、それぞれ異なる性質と役割を持たせたオブジェクトの様々な定義と、それらオブジェクトを相互に作用させる様々なプロセスの設定を通して、プログラム全体を構築するソフトウェア開発手法である。

オブジェクト指向という用語自体は、計算機科学者アラン・ケイによって生み出されている。1962年公開の言語「Simula」にインスパイアされたケイが咄嗟に口にしたとされるこの造語は、彼が1972年から開発公開を始めた「Smalltalk」の言語設計を説明する中で発信されて1981年頃から知名度を得た。しかしケイが示したオブジェクト指向の要点であるメッセージングの考え方はさほど認知される事はなく、代わりにクラスとオブジェクトという仕組みを注目させるだけに留まっている。同時にケイの手から離れたオブジェクト指向は抽象データ型を中心にした解釈へと推移していき、1983年に計算機科学者ビャーネ・ストロヴストルップが公開した「C++」が好評を博したことで、オブジェクト指向に対する世間の理解は「C++」とそのモデルの「Simula 67」のスタイルで定着した。それに基づいてカプセル化、継承、ポリモーフィズムといった考え方も後年に確立された。

特徴

クラスベースとプロトタイプベース

OOPというパラダイムは、クラスベースとプロトタイプベースの二つのサブパラダイムに大別されている。クラスベースの代表格は「C++」「Java」「C#」であり、プロトタイプベースの代表格は「Python」「JavaScript」「Ruby」である。前者はクラスとインスタンスの仕組みを中心にしており、後者はメタクラスの仕組みを採用してクラスとインスタンスの境界を曖昧にしている。前者は静的型付けを重視しており、後者は動的型付けを重視している。2000年代以降になるとプロトタイプベースも静的なクラスを重視するようになったのでその純粋な存在感は失われつつある。本節でもクラスベースを基準にして説明する。

クラスとインスタンス

OOPの要点であるクラスとは、端的に言うと変数と関数をひとまとめにしたものであり、手続きを付けたデータ構造体とも解釈される。コンパイル時定義の静的型付けが普通である。クラスに属する変数はデータメンバまたはデータと総称され、言語別にフィールド、プロパティ、属性、メンバ変数といった名称になっている。クラスに属する関数はもっぱらメソッド、メンバ関数、メンバ手続きといった名称になっている。これだけの説明だとC言語やVisual Basic系などの非OOP言語で使用されるモジュールと、OOP言語のクラスは同じものに見えるが双方の間には明確な違いがあり、モジュールに抽象（abstraction）の考え方とその機能を導入したものがクラスである。抽象化のための機能とは後述のカプセル化、継承、ポリモーフィズムを指している。

クラスはデータとメソッドの構成を定義した型であるので、それを計算対象や代入対象になる値として扱うにはインスタンスに実体化（量化）する必要がある。その用法でのクラスはユーザー定義型と呼ばれる。クラスはインスタンスのひな型であり、インスタンスはクラスを量化したものである。ここでの量化とは、そのクラスに属する変数の値を全て決定してメモリに展開する行為を指す。言語によっては後述の仮想関数テーブルもセットで展開する。インスタンスは別名としてオブジェクトとも呼ばれる。OOPの主役であるオブジェクトの意味と用法は実は曖昧なのが現状であり言語ごとにも違いがある。

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

クラスベースOOPは抽象データ型の思想に準拠しており、その実装スタイルを規定した以下の三項目は、日本では三大要素または三大原則などと呼ばれている。非OOP言語のモジュールに三大要素仕様を加えたものがOOP言語のクラスになる。カプセル化はthis参照の機構とデータ/メソッドの可視性を指定できる機能、継承は自身のスーパークラスを指定できる機能、ポリモーフィズムはオーバーライドと仮想関数テーブルを処理できる機能である。

カプセル化

互いに関連するデータとメソッドをまとめてクラスとし、必要なデータとメソッドのみを外部公開し、それ以外をクラス内に隠蔽する機能をカプセル化と呼ぶ。外部公開されたデータとメソッドはクラス外からの直接アクセスが可能である。内部隠蔽されたデータとメソッドはクラス外からアクセスされないことが保証されこれは情報隠蔽と呼ばれる。同クラス所属のメソッドを通してのデータの閲覧と変更はそのデータの抽象化を意味することになりこれはデータ抽象と呼ばれる。この二つがカプセル化の要点である。データ抽象を実装するための仕組みでもあるthis参照については後節で述べられる。データ閲覧用メソッドはゲッター、データ変更用メソッドはセッターと呼ばれる。データとメソッドの外部公開範囲を、無制限・任意クラスグループ・派生クラスグループの三段階に分けて定義する機能はアクセスコントロールと呼ばれる。

継承

既存クラスのデータ/メソッド構成に任意のデータ/メソッド構成を付け足して、既存構成＋新規構成の新しいクラスを定義する機能を継承と呼ぶ。その差分プログラミング目的の継承よりも、既存構成に抽象メソッドを置いて新規構成にその実体メソッドを置くというオーバーライド目的の継承の方が要点にされている。新規構成ではなく実装内容を付け足していくための継承である。既存クラスは基底クラス、親クラス、スーパークラスなどと呼ばれ、新しいクラスは派生クラス、子クラス、サブクラスなどと呼ばれる。抽象メソッドを持つクラスは抽象クラスと呼ばれる。継承できるクラスが一つに限られている単一継承を採用している言語と、継承できるクラスの数に制限がない多重継承を採用している言語に分かれている。抽象メソッドのみで構成される純粋抽象クラスの継承は、インターフェースの実装継承と呼ばれて抽象化目的の継承になる。

ポリモーフィズム

異なる種類のクラスに同一の操作インターフェースを持たせる機能をポリモーフィズム（多態性）と呼ぶ。これはクラスの継承関係を利用して、コンパイル時のメソッド名から呼び出されるプロセス内容を実行時に決定するという仕組みを指す。その実装は仮想関数と呼ばれており、クラスベースOOPのポリモーフィズムはイコール仮想関数となっている。仮想関数はスーパークラスの抽象メソッドの呼び出しを、それをオーバーライドしたサブクラスの実体メソッドの呼び出しにつなげる機能である。抽象メソッドとオーバーライド機能については後節で述べる。ポリモーフィスムの要点は、同じメソッド名からその実行時に対応した異なる処理内容を呼び出せるようにすることである。

コンポジションとデリゲーション

コンポジション（合成）とデリゲーション（委譲）は、継承の原型的仕組みであり、別の言い方をすると合成＋委譲を最適化した機能が継承である。継承はis-a構造の委譲、合成はhas-a構造の委譲と読み替える事ができる。合成とは、クラスに特定処理の委譲先となる部品クラスを複数持たせた構造であり、合成クラスがデータ/メソッドを要求されて自身が未所持の場合は、対応可能な部品クラスを選択して委譲するという仕組みである。その要求判別と選択過程を自動化したのが継承であり、部品クラスを親クラスに置き換えて暗黙の委譲先にしたものである。しかしその暗黙委譲は実際に参照されるデータ/メソッドの把握を困難にするという欠点も明らかになったので、合成の価値が再認識されるようになった。既存構成に新規構成を付け足していく差分プログラミング目的では、継承よりも合成を用いる方がよいと考えられている。

動的ディスパッチとメッセージパッシング

動的ディスパッチはポリモーフィズムの原型的仕組みであり、継承構造上でのthis参照によるシングルディスパッチを最適化した機能が仮想関数である。動的ディスパッチはコンパイル時のメソッド名から呼び出されるメソッド内容が実行時に決定される仕組み全般を指す用語であり、メソッド名を基軸にして各引数の型によってプロセスが選択分岐される仕組みを意味するシングルディスパッチと多重ディスパッチを包括している。一つの引数の型がプロセス選択に影響するのはシングル、二つ以上なら多重になる。

メッセージパッシングでは、引数の型に加えてメソッド名も実行時に解釈される要素にされておりそれはセレクタと呼ばれる。object selector: paramような書式でオブジェクトの共通窓口となるメッセージレシーバーにセレクタと引数のメッセージが送られる。また、object.call(method_name, param)のような書式でオブジェクトの共通窓口関数をコールするのもメッセージパッシングと呼ばれる。これは遠隔手続きコールやオブジェクト要求ブローカーで用いられており分散オブジェクトの標準的なインターフェース機構になっている。関数名（=メソッド名）も実行時に解釈されるという特徴を指してメッセージパッシングと呼ぶ。よく用いられるセレクタ対応プロセスを自動選択化してコンパイル時最適化した仕組みがメソッドになり、これは関数名をコンパイル時決定する関数呼び出しと同類になった。

インターフェース

インターフェースはカプセル化を更に突き詰めた仕組みであり、データ抽象とメソッド抽象と情報隠蔽を合わせて実現する最もOOPらしい機能と言える。インターフェースは抽象メソッドのみで構成されている純粋抽象クラスである。ゲッター、セッター、プロセスになる各抽象メソッドの実装内容は利用者側から隠されて実行時のその都度に決定される。

プロトタイプとオブジェクト

クラスベースのクラスと実体化とインスタンスは、プロトタイプベースではプロトタイプと複製とオブジェクトに置き換わる。プロトタイプとオブジェクトは双方とも、プロパティとメソッドを自由に付け替え可能にされておりこれは動的バインディングとも呼ばれ、そのプロパティとメソッドの構成による型はダックタイピングで判別される。この特徴は同時にポリモーフィズムになる。その用法は関数オブジェクトと変数オブジェクト（値オブジェクト）に大別され、前者のプロパティは二階述語論理、後者のメソッドは高階述語論理の表現体になり、それ自体がメタ視点から抽象化されたオブジェクトにはカプセル化という概念は必要でなくなる。継承では委譲先になる部品オブジェクトの自由な合成が重視されており、その部品はトレイトと呼ばれる事が多くその合成は多重継承と同義になる。前述のコンポジションはhas-a構造であるが、トレイトはis-a構造の合成である。トレイトの実装はもっぱら構造的型付けで判別される。プロトタイプベースは動的な関数型プログラミングに似た性質になっているが、オブジェクトの柔軟な用法に対しての一定の枠組みが必要であるとも考えられて静的なクラス定義が積極的に導入されるようになり、現状では関数型とOOPのハイブリッドのようなパラダイムに落ち着いている。

メッセージング

メッセージングはオブジェクト指向の父であるアラン・ケイが最重視していた源流思想である。これは当時のLISP風プログラミングの変化球と言えるものであり、関数型プログラミングと対比させると分かりやすくなる。関数（写像）を値に適用するという関数型の基本形に対して、メッセージングでは写像をただのシンボル（=セレクタ）にしており、写像を融合させた値（=オブジェクト）にセレクタを送ると、その値専用の写像がセレクタ別に呼び出されるようになっている。写像から計算式を取り除いてただの象徴記号にしたものがセレクタであり、値と写像を融合したものがオブジェクトである。セレクタには引数としてのオブジェクトを続かせられる。セレクタ用法はたらい回し的なデリゲーションに適しているようである。メッセージングベースのOOPは恐らく永遠の途上段階にあるので、このセレクタ構文を用いているか否かが現在に到るまでの類別基準になっている。

歴史

1954年に初の高水準言語・FORTRANが登場すると、開発効率の劇的な向上と共にソフトウェア要求度も自然と高まりを見せてプログラム規模の急速な拡大が始まった。それに対応するために肥大化したメインルーチンをサブルーチンに分割する手法と、スパゲティ化したgoto命令を制御構造文に置き換える手法が編み出され、これらは1960年に公開された言語「ALGOL60」で形式化された。当時のALGOLはアルゴリズム記述の一つの模範形と見なされたが、それと並行して北欧を中心にした計算機科学者たちはより大局的な観点によるプログラム開発技法の研究を進めていた。

Simulaの開発（1962 - 72）

1962年、ノルウェー計算センターでモンテカルロ法シミュレーションを運用していた計算機科学者クリステン・ニゴールは、ALGOL60を土台にしてProcessと呼ばれるコルーチン機構を加えたプログラミング言語「Simula」を公開し、続けてその拡張にも取り組んだ。ニゴールの同僚で、1963年にSimulaを汎用機UNIVAC系統上で運用できるように実装した計算機科学者オルヨハン・ダールは、Processにローカル変数構造を共有する手続き（サブルーチン）を加えてパッケージ化する言語仕様を考案し、これは一定の変数と手続きをまとめるモジュールと同類の機能になった。程なくしてALGOL60コンパイラに準拠していての限界を悟ったニゴールとダールは、1965年からSimulaを一から再設計するように方針転換した。その過程で彼らは、計算機科学者アントニー・ホーアが考案して1962年のSIMSCRIPT（FORTRAN用のスクリプト）に実装していたRecord Classを参考にしている。Record Classはソースコード水準の抽象表現を、各汎用機に準拠したマシンコード水準の実装符号に落とし込む段階的データ構造のプログラム概念であった。これをモデルにした継承と、その継承構造を利用した仮想手続き（仮想関数）の仕組みも考案され、上述のパッケージ化されたProcess（モジュール）に継承と仮想手続きの両機能を加えたものを「クラス」と定義し、クラスをメモリに展開したものを「オブジェクト」と定義する言語仕様がまとまり、1967年に「Simula67」が初公開された。オブジェクトという用語は、MITの計算機科学者アイバン・サザランドが1963年に開発したSketchpad（CADとGUIの元祖）の設計内にあるObjectが先例であった。Simula67コンパイラはまずUNIVAC上で運用され、翌年から汎用機バロースB5500などでも稼働されて北欧、ドイツ、ソ連の各研究機関へと広まり、1972年にはIBM汎用機System/360などにも導入されて北米全土にも広まった。その主な用途は物理シミュレーションであった。

influenced by Sketchpad, Simula, the design for the ARPAnet, the Burroughs B5000, and my background in Biology and Mathematics, I thought of an architecture for programming.
（Sketchpad、Simula、ARPAネット、バロースB5000、それと専攻していた生物学と数学に影響されて僕はプログラミングアーキテクチャを思索していた） — Alan Kay

構造化プログラミングの提唱（1969 - 75）

Simulaの普及と前後して1960年代半ばになると、プログラム規模の際限ない肥大化に伴う開発現場の負担増大が顕著になり、いわゆるソフトウェア危機問題が計算機科学分野全般で取り沙汰されるようになった。その解決に取り組んだ計算機科学者エドガー・ダイクストラは、1969年のNATOソフトウェア工学会議で「構造化プログラミング」という論文を発表しトップダウン設計、段階的な抽象化、階層的なモジュール化、共同詳細化（抽象データ構造と抽象ステートメントのjoint）といった構造化手法を提唱した。ダイクストラの言う構造化とは開発効率を高めるための分割統治法を意味していた。なおこの構造化プログラミングは後に曲解されて制御構造文を中心にした解釈の方で世間に広まり定着している。共同詳細化は抽象データ構造を専用ステートメントを通して扱うという概念である。これはSimulaの手続きを通してクラス内の変数にアクセスするという仕組みをモチーフにしていた。段階的な抽象化と階層的なモジュール化は時系列的にも、SIMSCRIPTの段階的データ構造と、Simura67の継承による階層的クラス構造を模倣したものであった。ダイクストラ、ホーア、ダールの三名は1972年に『構造化プログラミング』と題した共著を上梓していることから互いの研鑽関係が証明されている。その階層的プログラム構造という章の中でダールは、Simulaの目指した設計を更に明らかにした。

I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.
（僕は型アンチではないが、全くうんざりしない型システムも知らない、だからまだ動的型付けを好んでいる） — Alan Kay

1974年にMITの計算機科学者バーバラ・リスコフは「抽象データ型」というプログラム概念を提唱し、ダイクストラが提示したモジュールの共同詳細化を、その振る舞いによって意味内容が定義される抽象データという考え方でより明解に形式化した。一方、1970年に構造化言語Pascalを開発していた計算機科学者ニクラウス・ヴィルトは、ダイクストラによる共著出版後の1975年にモジュール化言語Modulaを提示してモジューラプログラミングというパラダイムを生み出している。このようにいささか奇妙ではあるが、Simulaのクラスとオブジェクトというプログラム概念は、巷で言われる構造化からモジュール化へといった進化の流れとは関係なく、しかもその前段階においてさながら彗星のように生まれたパラダイムであった。

Smalltalkとオブジェクト指向の誕生（1972 - 81）

Simula発のProcessとクラスの示した可能性は、パロアルト研究所の計算機科学者アラン・ケイによるオブジェクト重視と「メッセージング」という考え方のヒントになった。ケイはプログラム内のあらゆる要素をオブジェクトとして扱い、オブジェクトはメッセージの送受信でコミュニケーションするという独特のプログラム理論を提唱した。それには関数適用風の書式を用いたオブジェクト同士の多種多様なデリゲーションと、プログラムコードとしても解釈できるデータ列を送信してそれを評価（eval）することで新たなデータを導出できるなどのアイディアが盛り込まれていた。オブジェクトが送るか受け取ったメッセージは任意のタイミングで評価できるので非同期通信や単方向通信をも可能にしていた。この発想の背景にはLISPの影響があった。オブジェクトとメッセージングの構想に基づいて開発された「Smalltalk」はプログラミング言語とGUI運用環境を併せたものとなり、1972年にデータゼネラルNova上での1000行程度のBASICを使った試作（概念実証）を経て、翌1973年に新開発されたゼロックスAlto上で本格稼働された。Smalltalkの設計を説明するためにケイが考案した「オブジェクト指向」という用語はここで初めて発信された。またケイのメッセージング構想はMITの計算機科学者カール・ヒューイットに能動的なプロセス代数を意識させて、1973年発表のアクターモデルのヒントにもなっている。しかしデリゲーションの多用とデータ列が常にコード候補として扱われる処理系は、当時のコンピュータには負荷が大きく実用的な速度を得られないという問題にすぐ直面した。Smalltalk-74（新たに開発されたBitBLTを使った高速描画版Smalltalk-72）からSmalltalk-76の過程で、やむなくメッセージは（多くの場合）関数の動的コールに、メソッドはパターンマッチ処理から単なる関数へ置き換えられるなど構想時の柔軟さが失われるほど最適化された。また、ケイの留保した継承機構も導入されてオブジェクトは抽象データ型の性格も有するようになった。

Smalltalk is not only NOT its syntax or the class library, it is not even about classes. I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea.The big idea is "messaging"...
（Smalltalkはその構文やライブラリやクラスをも関心にしていないという事だけではない。多くの人の関心を小さなアイディアに向かせたことから、僕はオブジェクトという用語を昔作り出したことを残念に思っている。大切なのはメッセージングなんだ。） — Alan Kay

1980年のSmalltalk-80は、元々はメッセージを重視していたケイを自嘲させるほど同期的で双方向的で手続き的なオブジェクト指向へと変貌していた。それでも動的ディスパッチと委譲でオブジェクトを連携させるスタイルは画期的であり、1994年に発表されるデザインパターンの模範にもされている。1981年に当時の著名なマイコン専門誌『BYTE』がSmalltalkとケイ提唱のオブジェクト指向を紹介して世間の注目を集める契機になったが、ケイの思惑に反して技術的関心を集めたのはクラス機構の方であった。オブジェクト指向は知名度を得るのと同時に、Simula発のクラスとそれを理論面から形式化した抽象データ型を中心に解釈されるようになり、それらの考案者がケイの構想とは無関係であったことから、オブジェクト指向の定義はケイの手を離れて独り歩きするようになった。

C++の開発と普及（1979 - 88）

Simulaを研究対象にしていたAT&Tベル研究所の計算機科学者ビャーネ・ストロヴストルップは、1979年からクラス付きC言語の開発に取り組み、1983年に「C++」を公開した。C++で実装されたクラスは、Simula譲りの継承と仮想関数に加えて、レキシカルスコープの概念をクラス構造に応用したアクセスコントロールを備えていた。C++で確立されたアクセスコントロールはカプセル化の元になったがコードスタイル上ほとんどザル化されており、その理由からストロヴストルップ自身もC++は正しくない（not just）オブジェクト指向言語であると明言している。1986年にソフトウェア技術者バートランド・メイヤーが開発した「Eiffel」の方は、正しいオブジェクト指向を標榜してクラスのデータ抽象を遵守させるコードスタイルが導入されていた。クラスメンバ（フィーチャー）は属性、手続き、関数の三種構成で、手続きで属性を変更し関数で属性を参照するという形式に限定されており、これは抽象データ型の振る舞い意味論に沿った実装であった。アクセスコントロールはモジューラプログラミングの情報隠蔽に沿った方式になり、仮想関数機能は延期手続き/関数として実装された。

I made up the term ‘object-oriented’, and I can tell you I didn’t have C++ in mind.
（僕はオブジェクト指向という言葉を作ったけど、C++（のような言語）は考えていなかった） — Alan Kay

1986年からACMがオブジェクト指向会議（OOPSLA）を年度開催し、そのプログラミング言語セクションでは抽象データ型の流れを汲むクラス・パラダイムが主要テーマにされ、それを標準化するための数々のトピックが議題に上げられている。モジュール性、情報隠蔽、抽象化、再利用性、階層構造、複合構成、実行時多態、動的束縛、総称型、自動メモリ管理といったものがそうであり、参画した識者たちによる寄稿、出版、講演を通して世間にも広められた。そうした潮流の中でストロヴストルップはデータ抽象の重要性を訴え、リスコフは基底と派生に分けたデータ抽象の階層構造の連結関係について提言した。契約による設計を提唱するメイヤーが1988年に刊行した『オブジェクト指向ソフトウェア構築』は名著とされ、Eiffelを現行の模範形とする声も多く上がった。ただしこれは学術寄りの意見でもあったようで、世間のプログラマの間では厳格なEiffelよりも柔軟で融通の利くC++の人気の方が高まっていた。他方でオブジェクト指向本来の原点であるメッセージ・メタファに忠実であろうとする動きもあり、1984年に開発された「Objective-C」はSmalltalkをモデルにしてそれを平易化した言語であった。そのメッセージレシーバーは静的なメソッド機構優先の動的ディスパッチ機構という方式で実装された。メッセージレシーバの仕組みは遠隔手続き呼出し/オブジェクト要求ブローカーの実装に適していたので分散システムとオブジェクト指向の親和性を認識させることになった。

SmalltalkとLISPコミュニティ（1979 - 91）

パロアルト研究所のアラン・ケイがその影響を言及していたLISPコミュニティでは1970年代後半から、Smalltalkが提唱するオブジェクト指向とLISPプログラミングの融合が研究されており、LISPのオブジェクト指向拡張版と称されたFlavorsが、1979年からMIT人工知能研究所のLISPマシン上で実装されるようになった。Flavorsを発端にしたオブジェクト指向デザインの潮流は、Common Lispにも汲まれて1988年に「Common Lisp Object System (CLOS)」が発表された。CLOSはメタクラス、ミックスイン、メソッドコンビネーションといった特徴的なプログラム概念を備えていた。メタクラスはクラスメンバの動的可変の有用性を投げかけ、ミックスインはデータ構成の単一継承とメソッド構成の多重継承を併用するクラス階層構造の有用性を後続のオブジェクト指向言語に提示した。メソッドコンビネーションの方はアスペクト指向のルーツになっている。CLOSの設計思想は『The Art of the Metaobject Protocol』の名でまとめられて1991年にパロアルト研究所フェローから著述発表されており、その真意は不明であるがアラン・ケイから「OOPへの最も深い洞察と最も実用的な洞察の数々」と評論されている。同じくパロアルト研究所では、Smalltalk方言を発端にした「Self」が1986年に開発スタートし、その開発チームが移籍したサン社から1990年に一般リリースされた。Selfはメタクラス仕様を、プロトタイプと称したクラスのみならずオブジェクトと称したインスタンスの方にも備えさせて、後にプロトタイプベースと呼ばれるオブジェクト指向スタイルを開拓した。

コンポーネントとネットワーク（1989 - 97）

ネットワーク技術の発展に連れて、データとメソッドの複合体であるオブジェクトの概念は、分散システム構築のための基礎要素としての適性を特に見出される事になり、IBM社、アップル社、サン社などが1989年に共同設立したOMGは、企業システムネットワーク向け分散オブジェクトプログラミングの標準規格となるCORBAを1991年に公開した。その前年にマイクロソフト社はウェブアプリケーション向けの分散オブジェクト技術となるOLEを発表し、1993年にはCOMと称するソフトウェアコンポーネント仕様へと整備した。このCOMの利用を眼目にしてリリースされた「Visual C++」「Visual Basic」はウェブ時代の新しいプログラミング様式を普及させる先駆になった。この頃に抽象データ型のメソッドを通したデータ抽象、データ隠蔽、アクセスコントロールおよび分散オブジェクトのインターフェース機構によるプログラムの抽象化といった概念は、カプセル化という用語にまとめられるようになった。クラスの継承が最もオブジェクト指向らしい機能と見なされていたのが当時の特徴であった。継承構造を利用した振る舞いサプタイピングは多態性という用語に包括された。こうしていわゆるオブジェクト指向の三大要素がやや漠然と確立されている。1996年にサン社がリリースした「Java」は三大要素が強く意識されたクラスベースであり、その中の分散オブジェクト技術はBeansと呼ばれた。類似の技術としてアップル社もMacOS上でObjective-Cなどから扱えるCocoaを開発している。また、1994年から96年にかけて「Python」「Ruby」「JavaScript」といったオブジェクト指向スクリプト言語がリリースされ、従来のクラスベースに対する新しいプロトタイプベースを定着させている。1994年のGOFデザインパターンの発表と、1997年にOMGが標準モデリング言語として採用したUMLは、オブジェクト指向プログラミングの標準化を促進させた。

... 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

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

オブジェクト指向言語は、抽象データ型に準拠したクラスベース、メタクラスを採用したプロトタイプベース、Smalltalkを規範にしたメッセージングベースの三タイプに分類されるのが一般的である。クラスベースでは「C++」「Java」「C#」が代表的である。プロトタイプベースでは「Python」「JavaScript」「Ruby」が有名である。メッセージングベースでは「Smalltalk」「Objective-C」「Self」などがある。言語仕様の中でオブジェクト指向の存在感が比較的高い代表的なプログラミング言語は以下の通りである。

Simula 67 1967年

1962年に公開されたSimulaの後継バージョンであり、クラスのプログラム概念を導入した最初の言語である。物理モデルを解析するシミュレーション制作用に開発されたもので、クラスをメモリに展開したオブジェクトはその観測対象要素になった。Simulaのクラスは、一つのローカル変数構造と複数のプロシージャをまとめたミニモジュールと言えるものであったが、継承と仮想関数という先進的な設計を備えていた事でオブジェクト指向言語の草分けと見なされるようになった。クラスベースの源流である。

Smalltalk 1972年

メッセージングのプログラム概念を導入した最初の言語。数値、真偽値、文字列から変数、コードブロック、メタデータまでのあらゆるプログラム要素をオブジェクトとするアイディアを編み出した最初の言語であり、プロトタイプベースの源流にもなった。オブジェクト指向という言葉はSmalltalkの言語設計を説明する中で生み出された。オブジェクトにメッセージを送るという書式であらゆるプロセスを表現することが目標にされている。動的ディスパッチと動的バインディング相当の機構であるメッセージレシーバーとデリゲーションは、後年のデザインパターンのモデルにもされた。GUI運用環境に統合された専用のランタイム環境上で動作させる設計も模範にされ、これは後に仮想マシンや仮想実行システムと呼ばれるものになる。

C++ 1983年

C言語にクラスベースのオブジェクト指向を追加したもの。Simulaの影響を受けている。静的型付けのクラスが備えられてカプセル化、継承、多態性の三仕様を実装している。カプセル化ではアクセス修飾子とフレンド指定子の双方から可視性を定義できる。継承は多重継承、オーバーライド制約用の継承可視性、菱形継承問題解決用の仮想継承も導入されている。多態性は仮想関数によるサブタイプ多相、テンプレートクラス&関数によるパラメトリック多相、関数＆演算子オーバーロードによるアドホック多相が導入されている。元がC言語であるため、オブジェクト指向から逸脱したコーディングも多用できる点が物議を醸したが、その是非はプログラマ次第であるという結論に落ち着いた。

Objective-C 1984年

C言語にメッセージングベースのオブジェクト指向を追加したもの。こちらはSmalltalkの影響を受けており、それに準じたメッセージパッシングの書式が備えられた。メッセージを受け取るクラスの定義による静的型付けと共に、メッセージを委譲するオブジェクトの実行時決定による動的型付けも設けられている。オブジェクト指向的にはC++よりも正統と見なされた。制御構造文が追加され、メッセージ構文も平易化されており、Smalltalkよりも扱いやすくなった。

Object Pascal 1986年

Pascalにクラスベースのオブジェクト指向を追加したもの。当初はモジュールのデータ隠蔽的なカプセル化、単一継承、仮想関数による多態性という基本的なものだった。静的型付け重視である。ヴィルト監修のアップル社による初回バージョンを土台にして様々な企業団体による派生版が公開されており、その特徴と機能追加も様々である。

Eiffel 1986年

C++の柔軟性と融通性とは正反対のオブジェクト指向言語。クラスベースで静的型付け重視である。契約による設計準拠のきめ細かなアサーションと例外処理の導入で堅牢性が高められている。クラスメンバ（フィーチャー）はデータ、アクセッサ、ミューテイタの三種限定でオーバーロードはできない。カプセル化の可視性は自身に依存するクラス（クライアント）を定義する形で決められる。多重継承可能であり、クラス間の繋がりを仮想継承機能、各種オーバーライド指定子、名前衝突を解決するリネーミング機能などで綿密に設定できる。多態性は延期関数/手続き（サブタイプ多相）とジェネリシティ（パラメトリック多相）である。ガーベジコレクション機能が初めて導入されたオブジェクト指向言語でもある。

Self 1987年

メッセージングベースのオブジェクト指向言語で当初はSmalltalkの方言として開発された。プロトタイプからインスタンスを複製して、プロパティとメソッドを動的バインディングできるという仕様が備えられている。プロトタイプベースというパラダイムはこのSelfから認知されるようになった。動的型付け重視である。Smalltalkと同様に専用のランタイム環境上で実行され、GUI運用環境の構築も目標にしていた。Selfのランタイム環境は実行時コンパイラ機能を初めて実装したことで知られており画期的な処理速度を実現している。この技術はJava仮想マシンの土台になった。

Common Lisp(CLOS) 1988年(ANSI規格化は1994年)

クラスベースのオブジェクト指向。メソッド記述の関数呼び出し形式への統合、多重ディスパッチ、クラスの動的な再定義等を特徴とする。

Python 1994年

プロトタイプベースのオブジェクト指向スクリプト言語。基本データ型やコレクション型などよく使われるデータ要素を全て組み込みのオブジェクトにしている。それらは手続き型スタイルでも気軽に扱える。コレクション型を扱うのに適した関数型構文も導入されている。関数/変数のオブジェクトは自由にプロパティとメソッドを付け足し付け替え可能である。オブジェクトはダックタイピングで型判別されるので変数/関数の型宣言と型注釈は撤廃されている。ゆえに動的型付け重視である。Pythonのプロトタイプはクラスと呼ばれている。多重継承可能であり親クラス要素のサーチ順序はC3線形化で解決されている。多態性は事実上メソッドの動的バインディングになっている。カプセル化は軽視されている。後期バージョンで型ヒントが追加され、それに伴いジェネリクスも導入された。

Java 1995年

C++をモデルにしつつ堅牢性とセキュリティを重視したクラスベースのオブジェクト指向言語。静的型付け重視である。パッケージ中心のカプセル化、単一のみの継承、仮想関数と多重実装可なインターフェースによる多態性と、基本に忠実なクラスベースである。C++風のポインタと値型インスタンスは除外されて参照型インスタンスに統一した。例外処理を整備し演算子オーバーロードを除外した。オブジェクト指向とマルチスレッドの調和が図られ、コンポーネント指向による動的クラスローディングの存在感が高められている。クラスメタデータを操作できるリフレクションは初期から採用された。中期からジェネリクス（パラメトリック多相）とメタアノテーション（アドホック多相）が導入され、ラムダ式と関数型インターフェースを軸にした関数型構文も採用された。仮想マシン上で実行される。仮想マシンとガーベジコレクションの技術は比較的高度と見なされている。

Delphi 1995年

Object Pascalを発展させたもの。それと同様にこちらも基本に忠実なクラスベースで静的型付け重視であった。当初はデータベース操作プログラム開発を主な用途にして公開された。クラスとレコード（構造体）に同等の比重が置かれていた。一時期Javaの対抗馬になった。

Ruby 1996年

Pythonを意識して開発されたオブジェクト指向スクリプト言語。Smalltalkを一つの理想にしてより万人向けの言語を目指し、動的型付けを重視している。日本で誕生してグローバル化したプログラミング言語である。LISPとSmalltalkのメタプログラミング的なオブジェクト指向から、PythonとJavaScriptのプロトタイプベースなオブジェクト指向までのスタイルとコーディング手法を幅広く取り入れている。

JavaScript 1996年

プロトタイプベースのオブジェクト指向スクリプト言語。型宣言と型注釈を撤廃してダックタイピングする動的型付け重視である。すべてをオブジェクトにするSmalltalkの思想に忠実な言語であり、Pythonと似ているがそれよりもプロトタイプベース性質と関数型プログラミング性質を追求している。定数、変数、構造体、関数などが全て同性質のオブジェクトにされており、プロパティとメソッドを自由に付け足したり付け替えできるようにデザインされている。関数オブジェクトの構築と用い方がプログラミング上のキーポイントになっており、クロージャ、高階関数、第一級関数、デコレータ、パイプラインといった多種多様な働き方とその組み合わせを柔軟に表現できる。WEBアプリケーション開発を主な用途にして公開されたのでオブジェクトはGUIパーツの構築にも最適化されている。ECMAScriptとして標準化されており、2015年版からはクラスベース向けの構文もサポートするようになった。

C# 2000年

Javaを強く意識してマイクロソフト社が開発したクラスベースのオブジェクト指向言語。Javaよりもマルチパラダイムの性質が強化されている。C++譲りの柔軟性と融通的を残しながら様々な糖衣構文サポートも加えてコーディング上の利便性がより高められている。マルチスレッド仕様も整備されている。アドホック多相では拡張メソッド、インデクサ、演算子オーバーロードなどを備えている。パラメトリック多相では共変/反変も扱えるジェネリクスを備えている。サブタイプ多相はクラスは単一継承でインターフェースは多重実装と基本通りである。関数型構文も整備されており、特にメソッド参照機能であるデリゲートの有用性が高められている。デリゲートはイベント駆動構文の平易な表現も可能にしている。基本は静的型付けであるが、動的束縛型とダックタイピングによる動的型付けの存在感が高められているので漸進的型付けの言語と見なされている。.NET Framework（共通言語基盤=仮想実行システム）上で実行される。

Scala 2003年

クラスベースのオブジェクト指向と関数型プログラミングを融合させた言語。クラス機構と関数型の型システムに同等の比重が置かれており静的型付け重視である。ミックスイン相当のトレイトと、共変/反変および抽象タイプメンバを扱えるジェネリクスを連携させた多態性が重視されておりオブジェクトを様々に派生型付けできる。シングルトンオブジェクトの役割が形式化されて従来のクラス静的メンバの新解釈にも用いられている。専用の定義書式によりイミュータブルなオブジェクトが重視されている。上述の派生型付けスタイルとオブジェクト引数の抽出構文とパターンマッチング式の併用連鎖計算はモナドを彷彿とさせて独特の関数型スタイルを表現できる。Java仮想マシン上で動作するJavaテクノロジ互換言語である。

Kotlin 2011年

静的型付けのクラスベースのオブジェクト指向であるが、手続き型プログラミングに回帰しており、クラス枠外の関数とグローバル変数の存在感が高められている。クラスはpublicアクセスとfinal継承がデフォルトにされて、カプセル化と継承が公然と軽視されている。これによりインスタンスは手続き型の関数の対象値としての役割が強められ、その操作をサポートする関数型構文も導入されている。仮想関数と抽象クラスによる多態性は標準通りである。Java仮想マシン上で動作するJavaテクノロジ互換言語である。

TypeScript 2012年

JavaScriptを強く意識してマイクロソフト社が開発したオブジェクト指向スクリプト言語。JavaScriptのプログラムを静的型付けで補完した言語である。クラスベース向けの構文と、関数型プログラミングの型システムのスタイルが加えられている。特に後者の性質が強調されている事から静的型付け重視である。継承構造によるサブタイプ多相はほぼ除外されており、ジェネリクスと型アノテーションでオブジェクトを扱うというパラメトリック多相とアドホック多相を重視するデザインになっている。オブジェクト指向ではあるが関数型の性格が強めである。

Swift 2014年

Objective-Cを発展させたものであるが、メッセージ構文は破棄されており、クラスベースのオブジェクト指向になっている。オブジェクトのイミュータブル性重視の構文が採用されている。プロテクト可視性の削除によってクラスの縦並びの継承は軽視されており、プロトコルの横並びの多重実装を重視している。プロトコルはインターフェースとミックスインの中間的機能であり、インスタンスはプロトコルを基準にして型分類され、また抽象化される。プロトコルとジェネリクスの連携による多態性が重視されている。モジュールの動的ローディングは不透明型の仕組みで補完されている。静的型付け重視である。

用語と解説

クラス

（class）の仕組みを中心にしたオブジェクト指向をクラスベースと言う。クラスはデータとメソッドをまとめたものであり、操作的意味論を付加された静的レコードとも解釈される。クラスはインスタンスのひな型であり、インスタンスはクラスを実例化（量化）したものである。クラスはカプセル化、継承、多態性の三機能を備えていることが求められている。カプセル化はthis参照の仕組みの実装およびデータとメソッドの可視性を指定できる機能である。継承は自身のスーパークラスを指定できる機能である。多態性はオーバーライドと仮想関数テーブルを処理する機能である。コンストラクタとデストラクタの実装も必要とされている。前者はインスタンス生成時に、後者はインスタンス破棄時に呼び出されるメソッドである。

プロトタイプ

（prototype）の仕組みを中心にしたオブジェクト指向をプロトタイプベースと言う。プロトタイプとは識別名＆中間参照ペアの集合体を指す。この集合体は一般にフレームと呼ばれる。識別名＆中間参照ペアの割り当て箇所は一般にスロットと呼ばれる。スロットにはデータとメソッドの識別名＆中間参照ペアが代入されるので、プロトタイプはクラスと同様にデータとメソッドをまとめたものになる。プロトタイプは言語によってはクラスと呼ばれている。プログラマはシステムが提供する基底プロトタイプに、自由にデータとメソッドを付け足して任意の派生プロトタイプを作成できる。プロトタイプは「型」相当であり、それを複製する方式で生成されるインスタンスは「値」相当である。データとメソッドはその参照にインスタンスを必要とするものと、しないものに分かれる。前者はインスタンスメンバ、後者は静的メンバに相当するものである。インスタンスにも自由にデータとメソッドを付け足すことができる。インスタンスはそのプロトタイプへの参照を保持しており、プロトタイプはその親プロトタイプへの参照を保持している。これは継承相当の機能になっている。インスタンスへの自由なメンバ付け替えは多態性相当の機能になっている。ただしプロトタイプは動的な関数型言語由来の仕様なのでクラスベースOOPの三大要素とはまた違った視点から眺める必要がある。

メッセージ

オブジェクト指向で言われるメッセージ（message）とは、オブジェクトの呼び出し側と呼び出される側の間であらゆる事柄が実行時に決められる仕組み全般を指す用語である。関数名の解釈、引数構成、返り値構成、関数名対応プロセス所有の是非、委譲先、同期/非同期タイミングといったものが実行時のその都度に決められる。実行時に解釈される関数名文字列はセレクタと呼ばれる。これは無制限に柔軟な仕様の関数呼び出しと考えてもよいものであり、その実装方式の明確な定義はない。代表例を挙げると分散オブジェクトや分散システムで用いられているメッセージパッシングは、関数名も実行時に解釈できる引数要素にした仕組みである。Smalltalk指向の言語に導入されているメッセージレシーバーとメソッドミッシングでは、特定のセレクタに対応するプロセスをコンパイル時定義できるようにして自動実行時選択されるようになっており、プロセス未定義セレクタだけが実行時解釈される仕組みになっている。このコンパイル時定義のセレクタプロセスをメソッドと呼んだ。OOPでメンバ関数をわざわざメソッドと呼ぶのはメッセージパッシング由来のこうした経緯からである。アラン・ケイはメッセージング（messaging）というより遠大な構想を持っていた。

インスタンス

（instance）はクラスベースではクラスを実例化（量化）したものであり、実装レベルで言うとデータ群と仮想関数テーブルをメモリ上に展開したものになる。プロトタイプベースではプロトタイプを複製する方式で生成されたオブジェクトを指す。実装レベルで言うとメモリ上に展開された識別名＆中間参照ペアの動的配列になる。

データメンバ

（data member）はクラスに属する変数。データ（data）とも略称される。言語によってフィールド(分節)、プロパティ(特性)、アトリビュート(属性)、メンバ変数と呼ばれる。データは、クラスデータとインスタンスデータに分かれる。クラスデータは静的データとも呼ばれる。その中で定数化されたものはクラス定数と呼ばれる。クラスデータはクラス名の名前空間でスコープされたグローバル変数と同じものであり、プログラム開始時から終了時まで確保される。インスタンスデータはインスタンス生成時にメモリ上に確保されるものであり、その破棄時に消滅する。インスタンスデータの参照にはそのthis参照が必要である。プロトタイプベースでは、プロトタイプで定義されたデータでそのアクセスにインスタンス（self）を必要としないものが静的データになる。

メソッド

（method）はクラスに属する関数。言語によってはメンバ関数、メンバ手続きとも呼ばれる。データの参照に特化したものはゲッター（getter）アクセッサ（accessor）と呼ばれる。データの変更に特化したものはセッター（setter）ミューテイタ（mutator）と呼ばれる。メソッドは、クラスメソッドとインスタンスメソッドに分かれる。クラスメソッドは静的メソッドとも呼ばれる。クラスメソッドはクラス名の名前空間でスコープされたグローバル関数と同じものである。インスタンスメソッドを呼び出すにはそのthis参照が必要である。プロトタイプベースでは、プロトタイプで定義されたメソッドでそのアクセスにインスタンス（self）を必要としないものが静的メソッドになる。

コンストラクタ

（constructor）はインスタンス生成時に呼び出されるそのクラスのメソッドである。インスタンスデータを任意の値で初期化するためのものであるが、その他の初期化コードも記述できる。プロトタイプベースではシステム提供プロトタイプが保持する生成用メソッドまたは生成用のグローバル関数がコンストラクタ相当になる。

デストラクタ

（destructor）はインスタンス破棄時に呼び出されるそのクラスのメソッドである。インスタンス破棄の影響を解決する任意の後始末コードを記述できる。インスタンスの破棄は占有メモリの解放を意味する。なお、ガーベジコレクタ実装言語ではファイナライザになっている事がある。プログラマが呼び出すデストラクタの方はその終了がメモリ解放に直結しているのに対し、ガーベジコレクタが呼び出すファイナライザの方はそうではない。

this参照

（this）は言語によっては「self」や「me」とも呼ばれる。instance.method()の書式で呼び出されたメソッド内で、そのインスタンスのメンバを暗黙アクセスできるようにするための仕組みである。instanceのアドレスが暗黙引数としてmethodに渡されて、そのmethod内でthisとなる。インスタンスのメンバアクセス時はこのthisが自動的に付加され、例えばdataがシステム内ではthis.dataのように変換されている。メソッドはインスタンスの実体化元（量化元）クラスで定義されているものである。これは、データにメソッドを付属させるカプセル化を実現するための仕組みである。this参照に対するsuper参照（super）は、サブクラスのインスタンスメソッド内で用いられるものであり、直上スーパークラスのデータ/メソッドにアクセスするための参照である。オーバーライドやドミナンスを無視してスーパクラスのメンバを呼び出すための仕組みである。

アクセスコントロール

（access control）は、カプセル化の情報隠蔽に基づいた機能であり、クラス内のデータとメソッドの可視性を決定する。可視性とはそれにアクセス（参照/変更）できる範囲を意味する。これにはレキシカルスコープ基準とクライアント基準の二通りがあるが、前者の方が一般的である。広く使われているレキシカルスコープ基準の可視性は、プライベート、プロテクト、パブリックの三種が基本である。プライベートは同クラス内のメンバからのみ、プロテクトは同クラス内と派生クラス内のメンバからのみ、パブリックはどこからでもアクセス可能である。クライアント基準の可視性は、自身メンバへのアクセスを許可するクライアントクラス（フレンドクラス）を定義する方法で決められる。そのクライアントの許可は同時にその派生クラスの許可も兼ねている事が多く、継承によるクラス群の一括定義を可能にする。

コピーコンストラクタ

（copy constructor）は、メソッドの引数に対する値インスタンスの値渡しの時に呼び出されるコンストラクタである。値渡しはインスタンス内容全体のメモリコピーであり、基本データ型では特に問題は生じないが、そうでないクラスのインスタンスでは例えばあるリソースへの参照を保持している場合に好ましくない保持重複が発生する事になる。呼び出されたコピーコンストラクタは値インスタンスを受け取り、単純コピーが許されない部分に任意の処理を施して生成した値インスタンスのコピーを引数へと渡す。

オーバーロード

（overloading）は、同じメソッド名（返り値の型＋メソッド名）にそれぞれ異なるパラメータリスト（引数欄）を付けたものを列挙してメソッドを多重定義する仕組みを指す。演算子もオーバーロード対象であり、単項演算子なら一つの引数の型、二項演算子なら二つの引数の型を多重定義することで演算対象の値の型ごとに計算内容をカスタマイズできる。任意個数の引数を多重定義できる( )演算子は、クロージャまたは関数オブジェクトの表現に用いられる。

オーバーライド

（method overriding）は、基底クラスで定義されたメソッド名義の呼び出しを、派生クラスで実装されたメソッド内容の実行につなげる機能である。これは基底メソッドを派生メソッドで上書きすると形容される。オーバーライドされた基底メソッドの内容はスルーされて派生メソッドの内容が実行される。メソッドシグネチャ（返り値の型＋メソッド名＋各引数の型と個数）が完全一致している基底側が派生側でオーバーライドされる。オーバーライド指定は、基底側のメソッドをvirtualやabstractで修飾する方式と、派生側のメソッドをoverrideやredefineで修飾する方式がある。前者では基底側でオーバーライド可否の定義が固定されるのに対して、後者では派生側で再定義できる。finalで修飾されたメソッドは再定義不可のオーバーライドの拒絶になる。オーバーライドメソッドの呼び出しは、基底クラスの型に代入された派生クラスのインスタンスで行われる。オーバーライドによって呼び出される内容が多相化されたメソッドは仮想関数と呼ばれる。仮想関数テーブル（virtual method table）はその多相化のための仕組みであり、メソッドシグネチャとメソッド内容アドレスがマッピングされている。

ドミナンス

（dominance）は言語によってハイディング（hiding）マスキング（masking）とも呼ばれる。継承による階層的クラス構造において、サブクラスのメンバがスーパークラスの同名のメンバを隠していることを指す。親クラスのAメソッドを子クラスが同名Aメソッドでドミナンスした場合、子の型で参照しているインスタンスはそこでAのサーチが止まって子Aが呼び出される。ただし親の型で参照すれば親Aを呼び出せる。オーバーライドと異なり、参照する型でインスタンスの振る舞いを変えるための単純な仕組みでもある。

仮想継承

（virtual inheritance）は、多重継承での菱形継承問題を回避するための仕組みである。菱形継承問題とは共にAクラスを親とするBクラスとCクラスの双方を継承した場合に、その継承構造上でAクラスが二つ重なって存在することになる不具合である。仮想継承では専用のテーブルが用意されて、そこでクラス名が参照アドレスにマッピングされる。BクラスからのAクラスと、CクラスからのAクラスは共に同じ参照アドレスをマッピングするのでAクラスはひとつにまとめられる事になる。同時に一度辿ったクラスは省略される事にもなる。

MRO

メソッド解決順序（method resolution order）は、多重継承時の親クラスの巡回順序を定義するものである。参照されたメソッドが自クラスにない場合はその親クラスを巡回してサーチされる。メソッドはクラスメンバと読み替えてもよい。これは深さ優先検索（deep-first）と幅優先検索（breadth-first）に分かれるが、オブジェクトの構造概念から深さ優先の方が自然とされている。従って一般的な多重継承では深さ優先検索が用いられて親クラスの重複は仮想継承で解決されている。しかし詳細は割愛するが、仮想継承部分の巡回順序に不自然さを指摘する意見もあったので、これを解決するために深さ優先と幅優先をミックスしたC3線形化（C3 linearization）というメソッド解決順序が考案された。C3線形化では親クラスの重複部分に対してのみ幅優先検索を適用することで、仮想継承を用いることなく菱形継承問題も自然に解決されている。

抽象クラス

（abstract class）は、全部または一部のメソッドが抽象化されているクラスを意味する。即ち抽象メソッドを持つクラスである。抽象メソッド（abstract method）は、メソッドシグネチャ（返り値の型＋メソッド名＋各引数の型と個数）だけが定義されてコード内容が省略されているメソッドである。抽象クラスはインスタンス化できないので継承専用になる。抽象メソッドはそのサブクラスの方でコード内容が実装されてオーバーライドされる。

インターフェース

（interface）はプログラム概念と機能名の双方を指す用語である。インターフェースは、抽象メソッドのみで構成される純粋抽象クラスを指しているが、言語によっては実体メソッドのメンバも許されている事がある。データはメンバにされないが、定数は許されている事がある。インターフェースはクラスの振る舞い側面を抜き出した抽象オブジェクトと解釈されている。クラスはインターフェースを実装継承し、多重継承可能である。インターフェースは自身を実装継承した下位概念クラスをグループ化できる。インターフェースは記名的型付けに準拠しているので実装されたインターフェース名の明記が自身の下位概念の判別基準にされる。抽象クラスと同様にインスタンス化はできない。言語によってはプロトコルとも呼ばれ、この場合は記名ではなくメンバ構成が自身の下位概念の判別基準になる構造的型付けの性質を備えたものにされている。

ミックスイン

（mixin）は、LISPのオブジェクト指向拡張版を起源にし、CLOSで認知されるようになったプログラム概念である。CLOSのミックスインは、クラスのデータ構成を単一継承にしてメソッド構成を多重継承にするというスタイルを指した用語になっている。これはクラス単一継承＋インターフェース多重実装に類似の概念であるが、メソッド構成にやや構造的型付けの性質がある点で異なっていた。

Selfを発端にしたプロトタイプベースの誕生以降は、トレイトを用いた多重継承スタイルを指す用語になっている。トレイトは委譲先になる部品オブジェクトであり、is-a構造のコンポジションになるので、普通のクラスと同様にデータメンバ/抽象メソッド/実体メソッドをメンバに出来るが、自身のインスタンス化は不可である。トレイトは自身を継承した上位集合クラスをグループ化できる。トレイトは専ら構造的型付けに準拠しているので所属メンバ構成自体が自身の上位集合の判別基準にされる。これはトレイト継承を明記していなくても、そのトレイトの全メンバを所持していれば継承扱いされることを意味する。構造的型付けのトレイトは合成や交差が可能である。トレイトは言語によってはプロトコルや構造型（structural type）とも呼ばれる。

型イントロスペクション

（type introspection）は一般に実行時型チェックと呼ばれるものである。プログラマが認知できない形でコンパイラまたはインタプリタが別途実装しているインスタンスの型情報を、実行時にその都度参照してインスタンスの型を判別する仕組みである。静的型付け下では専用の実行時型チェック構文（instanceofやdynamic_cast）によって型判別し、ダウンキャストなどに繋げられる。動的型付け下では変数への代入時や関数への引数適用時にランタイムシステムが自動的に型判別するようなものになる。型イントロスペクションでは型情報のタグ識別子が判定基準になっているので記名的型付けの考え方に準じている。

ダックタイピング

（duck typing）は、特定のメソッド名（メソッドシグネチャ）またはプロパティ名（データ名）の識別子を持っているかどうかでインスタンスをその都度分類する仕組みである。これはその場限りの型判別と言えるものである。判別されたインスタンスは自身が持つとされたメソッドまたはプロパティを呼び出される事になる。動的型付けの機能であり、ダックタイピングでは型情報の構成内容が判定基準になっているので構造的型付けの考え方に準じている。

型推論

オブジェクト指向下の型推論（type inference）は、型宣言ないし型注釈を省略して定義された変数の「型」が自動的に導き出される機能を指す。型はクラスと同義である。静的型付けの機能であり、コンパイラ/インタプリタがソースコードをあらかじめ解析し、初期値の代入を始めとしたその変数の扱われ方によって型を導き出す。ここで導き出される「型」とは他の変数への代入可能性や、関数の引数への適用可能性といったあくまで等価性の基準で決められるので、プログラマが人為的な意味付けによる型定義を重視している場合は予期せぬ結果が発生することにもなる。型推論は推論的型付けとも呼ばれ、普通に型宣言と型注釈を用いる明示的型付けの対極に位置付けられるが、昨今のオブジェクト指向言語では双方を併用するのが主流になっている。

メタクラス

メタクラス（metaclass）は、クラスのデータ、メソッド、スーパークラス、内部クラスなどの定義情報を記録したメタデータである。クラスベースのメタクラス機能は、実装レベルではシステム側が用意している特別なシングルトンオブジェクトと考えた方が分かりやすい。それにはシステム側が提供するインターフェースを通してのみアクセスできる。メタクラス内容を閲覧/変更できる機能はリフレクションと呼ばれる。プロトタイプベースでは、インスタンスの複製元であるプロトタイプ/クラス自体がメタクラス機能を備えており、データとメソッドを動的に付け替えできる。

リフレクション

（reflection）は、メタクラス内容を閲覧/変更する機能であるが、変更できる内容範囲は言語ごとに異なっている。データではデータ型、識別子、可視性が変更対象になる。メソッドではリターン型、識別子、パラメータリスト、可視性、オーバーライド指定が変更対象になる。双方の追加定義と削除もできる事がある。スーパークラスも変更できる事がある。メタクラスの変更はそのまま関連クラスと関連インスタンスに反映される。ただし反映範囲はこれも言語によって異なる。

また、実行時の文字列（char配列やString）をデータとメソッドの内部識別子として解釈できる機能もリフレクションであり、上述のメタクラス操作よりもこちらの方がよく用いられる。これは実行時の文字列データを用いてのデータ/メソッドへの動的なアクセスを可能にする。

メタアノテーション

（metadata annotation）はクラスに任意の情報を埋め込める機能である。情報とは文字列と数値からなるキーワード、シンボル、テキストである。プログラマが自由な形式で書き込んで随時読み取るものであるが、システムから認識される形式のものもある。実装レベルではメタクラスに書き込まれてリフレクション機能またはその糖衣構文で読み取ることになる。マーカーインターフェースの拡張とも見なされている。メタアノテーションはクラス単位だけでなく、言語によってはインスタンス単位やメソッド単位でも埋め込むことができる。

メソッド拡張

（method extension）は、クラス定義とは別の場所でそのクラスに対する追加メソッドを定義できる機能である。これは状況に合わせてデータ抽象の表現に幅を持たせることを目的にしている。これには数々の書式があるが代表的なのは、静的メソッドまたは静的関数の第1引数をthis修飾して、その第1引数のクラス（型）に対してその静的メソッドをインスタンスメソッドとして追加するというものである。静的メソッドはそのクラススコープ内の限定拡張にできる。静的関数はネスト関数にしてそのローカルスコープ内の限定拡張にできる。双方はグローバル用途にすることもできる。

動的ディスパッチ

（dynamic dispatch）は、コンパイル時のメソッド名から呼び出されるメソッド内容が実行時に決定される仕組み全般を指す用語である。メソッドに引数を渡しての呼び出しを、オブジェクトにメッセージを発送（ディスパッチ）することになぞらえた事が由来である。発送先は実行時に選択決定されるメソッド内容を指す。メッセージは「this参照×第1引数×第2引数..」といった直積集合で考えられているのでシングル、ダブル、マルチプルといった呼称になっている。発送先はthisおよび各引数の派生関係の組み合わせで選択される。thisの派生関係のみ影響しているものは仮想関数と呼ばれるシングルディスパッチになる。それがthisでなく引数ならばただのシングルディスパッチになる。thisまたは各引数の内の2個以上のオブジェクトの派生関係が影響しているものはマルチプルディスパッチになる。その中で特にthisと先頭引数の2個が影響して先頭引数インスタンスの仮想関数がthisを引数にしているVisitor形態のものはダブルディスパッチと呼ばれている。

動的バインディング

（dynamic binding）は、識別子が参照するまたは呼び出すオブジェクト、インスタンス、メソッド、データなどのプログラム要素が、コンパイル時ではなく実行時に決められる仕組み全般を指す用語である。識別子はいわゆる変数名や関数名などを指す。

遅延バインディング

（late binding）は、識別子が参照するオブジェクトをコンパイル時に決める事前バインディング（early binding）の対義語であり、この場合は識別子が参照するオブジェクトを実行時に決める動的バインディングと同じ意味で用いられる。また他方では動的バインディングの中で、特に実行コードの動的ローディング機能を通して実装される方を遅延バインディングとする考え方もある。実行コードとはDLLやクラスライブラリやモジュールなどを指しており、それらが内包するクラスやメソッドを専用の不透明型または動的束縛型に代入する。その呼び出しのための内部識別子はコンパイル時には存在していないことが多いので、実行時の文字列（char配列やString）を内部識別子に解釈するためのリフレクション機能が多用されることになる。

パッケージ

（package）は1個以上のクラスをまとめたものである。多くなったクラスをグループ化するための仕組みである。パッケージの定義は言語ごとに異なるが、名前空間（namespace）と同等の機能になっているケースが多い。実装レベルではパッケージ名は自動的にクラス名の接頭辞になってクラス名を差別化し、名前衝突を回避している。

モジュール

（module）は1個以上のクラスをまとめたものである。ここでは手続き型や構造化プログラミングでのそれではなく、OOP言語で扱われているモジュール概念について説明する。ただしその定義は言語間で様々である。上述のパッケージと同等の機能にしている言語もある。ミックスインのために使われる変数と関数のメンバグループをそれにしてトレイトと同等の機能にしている言語もある。また、クラス群の動的ローディングに焦点を当てたソフトウェアコンポーネント相当の機能にしている言語もある。この動的ローディングは遅延バインディングと同義になり、実行中プロセスへのクラス群の逐次追加を可能にしている。動的ローディング用途のモジュールでは、内包する基底クラスの詳細を明らかにしつつも、その派生クラスの種類と詳細を明らかにしていないケースが多々あるので、その派生クラスを代入するための動的束縛型は特に不透明型（opaque type）と呼ばれる。不透明型はもっぱら型制約と併せて用いられる。

モンキーパッチ

（monkey patch）はモジュールやスクリプトファイルなどの動的ローディングを用いて、インタプリタ実行後またはコンパイル後のソースコード内容を変化させる手法である。ソースコードに専用のフィルター処理を記述しておき、その中で任意の箇所を動的ローディングされたモジュール内のクラスや関数や変数で置き換えさせる事で、その時の配置モジュールに合わせた処理内容の変化を起こせる。モジュールを外せば専用のフィルター処理は無効になる。この置き換え（パッチ当て）は遅延バインディング相当である。ソースコードを変えなくてもよいのが条件である。

ジェネリクス

（generics）は、クラスメンバの任意の「型」を総称化したままのクラス定義を可能にし、そのクラスをインスタンス化する各構文箇所で「型」の詳細を決定できるようにしたコンパイル時の静的な機能である。言語によってはテンプレート（template）と呼ばれる。ここでの「型」とはデータの型やメソッドの引数値/返り値/計算値の型を指している。クラス内のそれらを総称化して型変数にし、コンストラクタ呼び出し時の仮型引数に実型引数を適用すると、型変数に実型引数を当てはめたインスタンスが生成される。総称化された型を持つクラスはジェネリッククラスと呼ばれる。特定の型に依存しないクラスを汎用的に定義できるので、型が違うだけの重複コードを削減できるという利点がある。

言語によっては、ジェネリッククラス同士を共変性と反変性による継承関係で結ぶことができる。これはジェネリッククラスに適用する実型引数の継承関係を、そのジェネリッククラス同士の継承関係にシフトする仕組みである。class 猫 extends 動物とするとList<猫>はList<動物>のサブクラスになる。共変性は実型引数の継承関係をそのままジェネリッククラスの継承関係にシフトするが、反変性ではこれを逆にする。共変性ではList<猫>はList<動物>のサブクラスだが、反変性ではList<動物>はList<猫>のサブクラスになる。共変性と反変性はまとめてバリアンス（variance）と呼ばれる事がある。

型制約

（type constraint）は、(A)ジェネリッククラスの型引数/型変数、(B)代入値の型が実行時に決められる動的束縛型の変数、(C)動的ローディング時に詳細が隠されたままの値が代入される不透明型の変数、などの宣言に用いられるものである。それぞれは制約用の基準クラスで記号修飾され、その基準クラス及びその派生型の値が代入、束縛、適用されるという宣言になる。(A)の型引数/型変数では基準クラス及びその派生クラスが適用される宣言になる。(B)の動的束縛型では基準クラス及びその派生型の値が代入される宣言になる。(C)の不透明型では基準クラス及びその詳細不明である派生型の値が代入される宣言になる。型制約は型境界（type bound）とも呼ばれる。これには上限と下限がある。型制約と上限型境界（upper type bound）は性質的に同義である。下限型境界（lower type bound）は、基準クラス及びその基底型の値が代入、束縛、適用されるという宣言になる。

タイプメンバ

（abstract type member）はジェネリッククラスのメンバ要素であり、ジェネリッククラス同士で型変数の内容をやり取りするための仲介要素である。Aクラスコンストラクタの型引数にBクラスを適用した際に、適切な代入定義が併記されたAクラス内のタイプメンバに、Bクラスがその内部で扱っている総称型もセットで適用できる。連想配列さながらにBクラスがキー的存在になってAクラスのタイプメンバ内容も決定されることから、この仕組みは関連型または連想型（associated type）と呼ばれる。

関数オブジェクト

（function object）はクラスベースでは、( )演算子オーバーロードによる実装と、デリゲートによる実装などがある。前者はインスタンスを単に関数名らしく見せるための糖衣構文である。後者のデリゲートは、メソッドシグネチャを型種にした関数ポインタ型の変数である。デリゲート変数にはインスタンスメソッドへの参照が代入されてそのインスタンス種類による処理の多相を表現できる。プロトタイプベースでは、関数はそのままプロパティ/メソッド（=関数のローカル変数/関数）を自由に付け替えできる（動的バインディング）オブジェクトになる。

コルーチン

オブジェクト指向下のイテレータとジェネレータは、コルーチン（coroutine）機構に基づいている。通常のサブルーチンがコールする側の復帰アドレスだけをスタックに積むのに対して、コルーチンはコールする側とコールされる側双方の復帰アドレスをスタックに積むというサブルーチン機構である。各要素への作用が記されたオペレータが無名関数やラムダ式などの形態でデータコンテナに渡されると、各要素をフェッチするデータコンテナと、フェッチされた要素を参照ないし加工するオペレータが交互にコールスタックを用いて連携動作を繰り返す。イテレータはデータコンテナの各要素にオペレータを適用してその結果値に置き換えていく機能である。ジェネレータは(A)データコンテナを複製してその複製先の各要素にオペレータを適用していくという更新コンテナ生成機能、(B)オペレータがデータコンテナの各要素を選別していき最後に全選別要素を結合したコンテナを生成する機能、(C)オペレータがデータコンテナを走査して各要素の総和値を生成する機能の三種がある。

メッセージレシーバー

（message receiver）は、メソッド名を文字列で受け取ることができる仕組みであり、インスタンスのデフォルトメソッド（共通窓口メソッド）として備えられるものである。メソッド名の次に引数が渡される。メソッド名文字列はセレクタとも呼ばれる。プログラマはセレクタをレシーバー内で自由に解釈して任意のプロセスに選択分岐できる。通常のinstance.method(arg)が、レシーバー機構ではinstance selector: argやinstance.receiver(method_name, arg)のようになる。受け取ったセレクタによる選択分岐をシステム側が自動化したものがメソッドになった。これの応用形であるメソッドミッシングは、インスタンスに事前定義されていないメソッドが呼び出された時にのみ、取りこぼし用のレシーバーが呼び出されて、文字列化されたメソッド名と引数が渡されるという仕組みである。

イミュータブル・オブジェクト

（immutable object）は、データ不変設定されたクラスのインスタンスを意味する。定数だけを持つインスタンス、不変文字列、不変プリミティブのボックス型、収納内容が不変のコレクション（Array、List、Set、Map）などを指す。イミュータブル（不変）はオブジェクトの性質というよりも、それを何のためにどう扱うかというアルゴリズムとデザインパターンの方が要点になる。不変オブジェクトは並行OOPと関数型OOPで最も重要視される。不変オブジェクトではセッターとミューテイタは禁止され、代わりに元への変更を反映して新たに生成したオブジェクトが返されることになる。コレクションクラスでは要素の追加/削除/変更による結果内容のコレクションが新たに生成されてそれが返り値にされまた引数用途にもなることから、これはファーストクラスコレクションと呼ばれる。なお、不変オブジェクトをコピーした専用の可変オブジェクトを取得したのならば、それへのセッターとミューテイタは許される。これはcopy-on-writeと呼ばれる。

デリゲーション

委譲（delegation）。呼び出されたあるクラスのメソッドが自分への引数を他のクラスの同名メソッドにそのまま渡して、その同名メソッドからの返り値をそのまま呼び出し元に渡すという仕組みを指す。委譲先のクラスはhas-a関係で保有されているものになる。委譲先メソッドは必ずしも同名ではなくマッピング名の場合もあり、引数も構成を変えて渡される場合もある。

フォワーディング

転送（forwarding）。委譲先のクラスのメソッドが処理を行わずに、そのまた他のクラスの同名メソッドに引数をそのまま渡して、その返り値をそのまま呼び出し元に渡している場合、冒頭の委譲は転送になる。転送用メソッドではどのクラスに引数をパスするかという選択が行われるので、デリゲーションの多相を表現できる。

サブタイピング

（subtyping）はクラス（型）のあらゆる派生関係および派生構造の実装形式とその働き方を包括したプログラム概念である。サブタイプ多相（subtype polymorphism）とも呼ばれる。継承、オーバーライド、コンポジション、ジェネリクス、共変反変バリアンス、不透明型といったものは全てサブタイピングの一側面である。オブジェクト指向でよく使われるものは、振る舞いサブタイピング（behavioral subtyping）であり、継承とメソッドオーバーライドの合わせ技である仮想関数がそれに当たる。

Is-a関係

（Is-a）は上位概念と下位概念のコンセプトを扱っており、下位概念is-a上位概念となる。オブジェクト指向ではクラスの継承関係および実装継承関係を意味する用語になっている。これには汎化・特化・実現・実装の四種がある。

• 汎化（generalization）は、サブクラスからスーパークラスへの連結を指す。
• 特化（specialization）は、スーパークラスからサブクラスへの連結を指す。
• 実現（realization）は、クラスからインターフェースへの連結を指す。
• 実装（implementation）は、インターフェースからクラスへの連結を指す。

Has-a関係

（Has-a）は上位集合と部分集合のコンセプトを扱っており、上位集合has-a部分集合となる。オブジェクト指向ではクラスの構成関係を意味する用語になっている。これには合成・集約・収容・依存の四種がある。なお、依存（dependency）はhas-a関係における依存とそれ以外のクラス間関係における依存の意味が異なる二つが存在する。

• 合成（composition）は強いhas-a関係であり、AクラスがBクラスをデータにし、Aクラスのコンストラクタと同時にBインスタンスが生成され、Aクラスのデストラクタと同時にBインスタンスが破棄される場合、AはBの合成となる。Bが自身のサブクラスで交換される場合は分離とともに破棄される。
• 集約（aggregation）は弱いhas-a関係であり、AクラスがBクラスをデータにし、Aクラスのコンストラクタとは関係なくBインスタンスが生成され、AクラスのデストラクタでBインスタンスが破棄されず、また分離時も破棄されない場合、AはBの集約となる。Aクラスがコレクション（配列、List、Set、Map）の仕組みでBインスタンスを持つ場合も、AはBの集約となる。
• 収容（containment）は弱いhas-a関係であり、集約と同じであるが、Aクラスがコレクション（配列、List、Set、Map）の仕組みでBインスタンスを持つ場合のみを指している。コレクション関係を強調する場合、AはBを収容しているとなる。
• 依存（dependency）は強いhas-a関係であり、Aクラスのいずれかのメソッドが、Bクラスを引数の型または返り値の型にしている場合、AはBに依存しているとなる。なお、AクラスがBクラスの型のデータをhas-aしている場合のAからBへの依存は、合成/集約の方で省略されている。

SOLID原則

（SOLID Principles）は、いわゆる抽象化に焦点を当てたクラスの設計原則である。(S)単一責任原則・(O)解放閉鎖原則・(L)リスコフの置換原則・(I)インターフェース分離原則・(D)依存性逆転原則といった五つから成り立っている。1988年にバートランド・メイヤーが提唱した(O)と、1994年にバーバラ・リスコフが提示した(L)に、ソフトウェア技術者ロバート・マーティンが(S)(I)(D)を加えて2000年に発表されている。

• (S)単一責任原則は、クラスをただ一つの機能を表現するようにデザインすることを推奨している。
• (O)解放閉鎖原則は、クラスを抽象クラスと実装クラスに分けてデザインすることを推奨している。抽象クラスの定義内容は変更に閉じられており、実装クラスの処理内容は拡張に開かれていることが由来である。
• (L)リスコフの置換原則は、実装クラスはその抽象クラスに対して振る舞い的に等価計算が可能であることを推奨している。抽象側の公開保有メソッドを実装側も全て保有していれば等価となる。ここでの置換（substitution）とは抽象クラスの型の変数に実装クラスの型のインスタンスを代入できることを意味している。
• (I)インターフェース分離原則は、一つのクラスから実現される抽象クラスを一つに限定せず、互いに処理内容に影響し合うメソッド群ごとに分離して複数実現することを推奨している。
• (D)依存性逆転原則は、AクラスがBクラスの機能を使用したい場合は、まずBからその抽象クラスをAに向けて実現し、Aはその抽象クラスを通してBの機能を使用することを推奨している。AはBの機能を使用するという意味でその抽象クラスに依存し、Bは自身の機能を提供するという意味でその抽象クラスに依存することになる。ここでの逆転（inversion）とは実装から抽象への方向性を意味している。

GOFデザインパターン

（Gang of Four Design Patterns）はソフトウェア開発において直面しやすい共通的かつ代表的なデザイン問題をピックアップし、それぞれの解決に最適なクラスパターン図を提示したものである。1994年から四人の計算機科学者ないしソフトウェア技術者たち（Gang of Four）によって発表され、OOPのデザインパターンの代表格と見なされた。教科書の内容としても取り上げやすい形式化されたトピックであったためにオブジェクト指向の学習面では非常に重視された。5個の生成パターン、7個の構造パターン、11個の振る舞いパターンに分類されている。

生成に関するパターン

Abstract factory

Builder

Factory Method

Prototype

Singleton

構造に関するパターン

Adapter

Bridge

Composite

Decorator

Facade

Flyweight

Proxy

振る舞いに関するパターン

Chain of Responsibility

Command

Interpreter

Iterator

Mediator

Memento

Observer

State

Strategy

Template Method

Visitor