プロトタイプベース

プロトタイプベース (Prototype-based) は、オブジェクト指向プログラミング（OOP）のスタイルのひとつであり、オブジェクトの生成に既存オブジェクトの複製を用いるスタイルを指している。これには直後にメンバを拡充するための空オブジェクトの複製も含まれている。このスタイルは、インスタンスベース（Instance-based）とも呼ばれている。これと対比されるOOPスタイルにクラスベースがある。
プロトタイプベースOOPの原点はSmalltalk方言のSelfであり、Smalltalkのクラスベース設計を平易化する試みから1987年に誕生している。他にはLua、JavaScript、Etoys、ECMAScript、REBOL、Io、TypeScriptなどがある。
プロトタイプとは、複製元になったオブジェクトを意味しており、複製先のオブジェクトから見てそう呼ばれる。プロトタイプは同時にそのオブジェクトの暗黙の委譲先になり、これはプロトタイプを複製が継承していることと同じになる。

**来歴**
プロトタイプベースは、Smalltalkのクラスベース設計を平易化する試みから考案されたスタイルなので、Smalltalkの設計を知らないとそれが作られた理由も分からないものになる。ここではアラン・ケイが概略したSmalltalk設計の六項目を紹介して、クラスベースに関連する部分を和訳しておく。(4)は数学的帰納な文章なので、インスタンスのひな型であるクラスもまたメタクラスのインスタンス化であり、そのメタクラスもまた他のメタクラスのインスタンス化であると解釈される。これは元祖クラスベースの大きな特徴であったが、実際はもう少し複雑でメタクラスとクラスの間に中間媒体が挟まれていた。i=インスタンス/C=クラス/M=メタクラスとするとインスタンス化の流れは、M → C class → C → iとなり、C classが中間媒体である。中間媒体は不変の静的型付け用としてオリジナルを保存し、クラスは可変の動的型付け用であった。
また、(3)で記憶（データ）はクラスとインスタンスの双方が持つが、(5)で振る舞い（メソッド）はクラスのみが保持するとされており、これも混乱を招きやすいネックになっていた。元祖クラスベース設計は理論面では美しかったが、実践面では甚だ複雑として開発陣からも不評になり、それは哲学的なインスタンス化チェーンと、クラスとインスタンスに対する振る舞いの妙に起因していた。
その改善策としての、オブジェクトからクラスとインスタンスの概念を無くしてしまおうという案が、プロトタイプベースの原点になっている。この案は言語視点では、クラスを無くしてインスタンスに一元化するとも解釈できるので、インスタンスベース（Instance-based）と別称された。クラスのインスタンス化を、インスタンスのクローンに置き換えることでSmalltalkクラス設計の改善が図られ、Selfはこの案に沿って制作されたSmalltalk方言であった。ここでは(1)の遵守が第一にされていた。
なお、C++/Pythonからの静的/動的クラスベース設計では、クラスとインスタンスを、型と値の役割に固定してインスタンス化の相互再帰を無くしたことから、インスタンスのみがオブジェクトになっている。メタクラスはクラス構成操作のリフレクション機能になっている。これは(1)の事実上の撤廃であった。
現在では、C++/Python発のクラスベース設計が多くの言語で採用されており、Self発のプロトタイプベースは少数派になっている。のみならずプロトタイプベースの代表格JavaScript、ECMAScriptではクラスベース構文が導入されるに到っており、TypeScriptはクラスベースとプロトタイプベースの折衷にされている。プロトタイプベースはやや汎用性に欠けてオブジェクト指向の主流にはなり得なかったという結論になる。

**概要**
Selfとは少し別の切り口から、Smalltalkクラスベース設計の平易化を図ったDouglas Crockfordは、JavaScriptのプロトタイプベースをこのように概略している。You make prototype objects, and then … make new instances. Objects are mutable in JavaScript, so we can augment the new instances, giving them new fields and methods. These can then act as prototypes for even newer objects. We don't need classes to make lots of similar objects… Objects inherit from objects. What could be more object oriented than that?（あなたはプロトタイプ・オブジェクトと新しいインスタンスを作る。オブジェクトは可変であり、新フィールドと新メソッドを加えて拡充できる。これもまた新生オブジェクトのプロトタイプになる。クラスは必要ない。オブジェクトも同様に継承できるからだ。これ以上のオブジェクト指向があるだろうか？）プロトタイプベースはプログラマに、オブジェクトをどう振る舞わせるかということのみに集中させて、オブジェクトが実際に振る舞えるかどうかの疑問を後回しにできる環境を提供する。振る舞いとはメソッドである。疑問の後回しとは動的型付けのダックタイピングを意味している。プロトタイプベースは静的型付けの実装を排除してる訳ではないが、その特性と利点を最大限に活かすための動的型付けが好まれている。
プロトタイプベースのオブジェクトは総じて、スロットの可変長配列として実装されている。スロットとは「シンボル＋コンテンツ」のペアデータである。シンボルはプロパティ名やメソッド名を表わし、コンテンツはプロパティ値やコードブロック参照を表わす。プロパティスロットはプロトタイプ参照やthis参照（self参照）の容器にもなる。Selfではメソッドスロットがメッセージ式で送られるセレクタの受け手になる。
オブジェクトの構築は、クローン方式かエクスニヒロ方式で行われる。クローン（clone）は既存オブジェクトを複製する方式であり、複製後にプロパティ/メソッドの自由な取り付け取り外しもできる。エクスニヒロ（ex nihilo）はプロパティ無しメソッド無しの空オブジェクトを生成（または複製）する方式であり、生成後にプロパティ/メソッドの自由な取り付けができる。構造体に似た書式でプロパティ/メソッドを初期設定して生成する方式もエクスニヒロに分類されている。クラス概念がないのでテンプレート処理的なオブジェクト構築は不可であるが、クラスベース構文が導入された言語では代替的に可能にされており、それはエクスニヒロの方で解釈されている。
クローンで構築されたオブジェクトのプロトタイプ-スロットには、クローン元になったオブジェクトの参照が自動代入される。プロトタイプ-スロットは再代入可能なので、エクスニヒロで構築された空オブジェクトにも、そのプロトタイプにするオブジェクト参照を自由に追加できた。プロトタイプは暗黙の委譲先になり、オブジェクトがアクセス要求されたプロパティ/メソッドを持っていない場合は、そのプロトタイプで自動サーチされる。これは継承になった。
プロトタイプベースのポリモーフィズムは、クラスがないことからメソッドオーバーライドによる仮想関数は成立しないが、オブジェクトのStructural type system解釈によるメソッドのサブタイピングがそれを担っている。また、動的型付けによる動的バインディングも用いられる。
プロトタイプベースでは、カプセル化は軽視されていることが多い。

**脚注**

**参考文献**
 isbn=978-1-4612-6445-3-  Class Warfare: Classes vs. Prototypes, by Brian Foote.- isbn=981-4021-25-3-  Using Prototypical Objects to Implement Shared Behavior in Object Oriented Systems, by Henry Lieberman, 1986.

**関連項目**
Self
*Lua
*JavaScript
*Io
*REBOL