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

オブジェクト指向プログラミング（オブジェクトしこうプログラミング、英: 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をモデルにしてそれを平易化した言語であった。そのメッセージレシーバーは静的なメソッド機構優先の動的ディスパッチ機構という方式で実装された。メッセージレシーバの仕組みは遠隔手続き呼出し/オブジェクト要求ブローカーの実装に適していたので分散システムとオブジェクト指向の親和性を認識させることになった。

コンポーネントとネットワーク（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

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

• Simula 67 1967年
• Smalltalk 1972年
• C++ 1983年
• Objective-C 1984年
• Object Pascal 1986年
• Eiffel 1986年
• Self 1987年
• Common Lisp Object System 1988年
• Python 1994年
• Java 1995年
• Delphi 1995年
• Ruby 1996年
• JavaScript 1996年
• C# 2000年
• Scala 2003年
• Kotlin 2011年
• TypeScript 2012年
• Swift 2014年

デザインパターン

GoF Design Patterns

GoFデザインパターンは、ソフトウェア開発における代表的なクラスデザイン問題をピックアップし、それぞれの解決に最適なクラスパターンを提示したものである。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

SOLID

SOLIDは、OOPにおける代表的なクラスの設計原則である。1988年にバートランド・メイヤーが提唱した(O)と、1994年にバーバラ・リスコフが提示した(L)に、ソフトウェア技術者ロバート・マーティンが(S)(I)(D)を加えて2000年に発表されている。

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