vieweditattachhistoryswikistopchangessearchhelp

プロトタイプベース・オブジェクト指向

prototype-based object oriented 。

オブジェクトがスロット（クラスのインスタンスならインスタンス変数やメソッドに相当）の追加をクラスに依存せずに自由にできることを前提としたオブジェクト指向。あるいはそうしたオブジェクトを用いたプログラミングや、それをサポートする機構。

「インスタンスベース」、「オブジェクトベース」とも。　これらへの言い換えは「プロトタイプベース」という言葉が持つ限定的なニュアンスを払拭するのにおおいに役立つ。しかし同時に、前者の「インスタンスベース」において特に、“プロトタイプベースにはクラスがない”あるいは“プロトタイプベースはクラスベースの対極にある（あるいはアンチテーゼである）”といったような教科書的記述に惑わされている人をひどく混乱させるらしく、極端な拒絶反応を示す人もいるので注意。また、後者においては、オブジェクトオリエンテッド＝オブジェクト指向と混同されてしまう危険を伴うので、実際に言い換える際には事前の但し書きなど、ある程度のコンセンサスが必要だろう。

「プロトタイプベース」という名称は、クラスでの定義の具体例（インスタンス）としてオブジェクトを生み出すのではなく、既存のオブジェクトの複製（クローン、コピー）、あるいは、それへの参照を持つことですべてを委譲するオブジェクト（チャイルド、シャローコピー）を生み出す手法を意識して作られた。しかし、このようなオブジェクト生成の手順は、本パラダイムにおいてそうすることが可能な“あえてクラスを排除した場合”に際立つ特徴にすぎず、けっして本質ではない（つまり、クラスがあって、クラスのインスタンスとして生成されたオブジェクトであっても、インスタンスベースのオブジェクトであり得る）。
--sumim

言語や環境


クラスベース・オブジェクト指向言語におけるプロトタイブベース的機能

--戯

--sumim

--sumim


関連

--sumim

クローンとチャイルド

プロトタイプベースのシステムにおいて、オブジェクトは“プロトタイプ”と指定した別のオブジェクトの仕様を、そのクローンあるいはチャイルドとして生じることで継承する（なお、クラスベースにおけるインスタンスとクラスの関係もこれと同種であるとの解釈が可能）。初期状態のチャイルドはすべてをペアレント（プロトタイプ）に委譲する。その後、独自のメソッドスロット（クラスベースでいうところの、インスタンスメソッド）や値スロット（同、インスタンス変数）を持てば差分となる。チャイルドの場合、プロトタイプと重複するメソッドやインスタンス変数を持てばオーバーライドとなる。

実手続きとしてチャイルドを作るときに clone（あるいは clone() ）を使用できるものと、clone は copy（shallow copy）と同義で、単にプロトタイプの複製を作るだけのものがありまぎらわしい。実は Io を除き、ほとんどの言語は後者で、むしろこのほうが一般的。つまり、我々が一般にイメージするクローン（じつはチャイルド）を clone で作ることはできない。ちなみに後者に属する言語で“チャイルド−ペアレント”関係を構築するには、スロットを持たない“始原オブジェクト”に委譲用の特殊なスロットを明示的に宣言し、そこにプロトタイプを束縛する作業が必要になる。

プロトタイプベースオブジェクトの柔軟性

プロトタイプベースでいいなぁと思うのは、クラスだとクラスＡのインスタンスはクラスＢのインスタンスには成り得ないけど、プロトタイプベースなら簡単にできてしまう…ということですね。ま、そもそもオブジェクトがクラスに属していないから当たり前っちゃあ当たり前ですが(^_^;)。Squeak でテーマを変えたとき既存のウインドウには影響を及ぼすことができない（せいぜい表示がくずれる）けど、プロトタイプベースならオブジェクトは指定された属性を持つようになるので既存の GUI ウィジェットであっても影響は直ちに及ぶのだろうなぁ…と、思いつつ。　もっとも、SELF の Morphic にテーマという概念があったとして、それが期待されるように動作できるのかどうかは試してみないとわからないけど。--sumim

プロトタイプベースは完全無欠なのか？

追記：この手の疑問は現在は“意味のないもの”として（私、sumim の中では）解決しています。当初は、クラスベース利用者の立場からなじみのないプロトタイプベースを、クラスベースとは相容れない対極のものと位置づけようとした（実際にそういう説明を多く目にした）ため、理解に無理が生じていました。実はプロトタイプベースは、クラスベースと相反するものではなく、クラスベースより一段階プリミティブなものだと考えると、つまり、プロトタイプベースにいろいろな機構（トレイトとしてクラス）や制約（独自メソッドの追加や再定義、インスタンス変数の追加を禁じる）を設けることによってできたのがクラスベースだと解釈すれば何ら問題がないことが分かりました。（時系列的には逆ですが）--sumim

一見、欠点の見当たらないプロトタイプベースだが、クラスベースに容易にできて、プロトタイプベースは実装が困難なものはないのか？--sumim

ぱっと思いつきですがクラスを型とみなして静的な型チェックができますね。
しかしMLのような型推論のシステムが応用できれば面白いのですが、なぜかCの時代から進歩していないという。--SHIMADA

Smalltalk が型チェックを入れてないのはコストがかかりすぎたからみたいです。まああと、Smalltalk が型チェックをばしばしやると Smalltalk っぽいアバウトさというか、設計者も考えつかない利用法とかができなくなっていかんというのもあるかなと。--sumim

ところで、プロトタイプを参照するのとは違うのでしょうか？　ああ、プロトタイプベースは、プロトタイプをほいほい変えられるから静的には型チェックができないわけですね。と自己完結。--sumim

Smalltalk だと、型推論機構とか相性がよさそうなのですが、だれかやっていないんでしょうかねぇ…。--sumim

結局のところ、とことん動的である(そう成り得る)ことを、喜ぶか悲しむか、という捉え方の差の話に落ちちゃうような気が。 -戯

結局、静的型言語やクラスベース言語などの静的指向は、「できないことを増やす」ことで却って嬉しがる指向なわけで。

なるほど。静的なものを“指向”することで幸せになろうとするスタンスなんすね。ちょっと腑に落ちつつあります。そういうパラダイムなら、たしかに Smalltalk なんかみたいにふにゃふにゃなものは許せないわな。逆に私のように、このふにゃふにゃ感や、とりあえずなんか組んでおいてあとで考えよう…的な人間には静的指向は窮屈で、思考をさまたげるからいやだと。--sumim

Cecilがまさに、クラスとプロトタイプを両方サポートすることでそれぞれの長所短所を補い合うということを目指した言語のようです。--やまねこ

見通しの悪さ、整然さに欠けるのは欠点か？

今日、久しぶりに SELF をいじってみたんですが、多重継承と目が慣れていないせいか、身近なオブジェクトのスロットがやたら多くて扱いづらい印象は正直持ちました。でもこれはどちらかというと IDE の UI 的側面で本質的なもんでもないですし、Smalltalk で言うところのシステムブラウザとインスペクタを同時に見ているから当たり前と言えば当たり前…。なのでプロトタイプベースの欠点と言うほどではないですね--sumim

全インスタンス(あるトレイトに依存しているオブジェクト)を把握する機構を導入しにくい？

プロトタイプベースだと、クラスベースとしての Smalltalk の allInstances みたいなのがやりにくいかな。そうでもないか…。--sumim

allInstances相当の機能って必須だと思わないです。生成した時に「誰かに」覚えていて貰えばいいのであって、それがClassである義務は無いという印象。 例えばDelphiのVCLのように、今後自分を覚えていてくれるObjectをコンストラクタの引数にする、というやり方で十分というか。 --戯

生成主に覚えておかせる（生成主が知っている）ってのが自然なだけで、そうでなくてはいけないということはありませんよね。たしかに。--sumim

TikiGuion:ばぶばぶ/dictとobjとclassの実装の統合 とかじゃ駄目っすか？-戯

以前、たしか HashedWiki 経由で拝見したときおもしろいなと思いました。マイチャレンジ queue に「Squeak 版 ばぶばぶ」を追加しておきます(笑)。--sumim

そういや、作り始めたけど面倒になって敵前逃亡したネタの中に、ruby版実装「ぶるぶる」とかjava版実装「じゃぶじゃぶ」なんてのが有りました(笑)。 -戯

じゃあ、「ずぶずぶ」ですね。いや「ばくばく」か。--sumim

ええと念のため。紹介した頁に描かれたかたちの実装は、まだ俺も作っていません(^^; 予定つーことで。 -戯

フレームワークを組み立てるのはスキル的に無理だと思いますが、シミュレータくらいは書けそうな気がするので。Smalltalk プログラミングの勉強の題材にさせていただきます。--sumim

メタ機構はどうなるのか？

まあ、allInstances は例が悪いので置いておいて、プロトタイプベースだと、オブジェクトの振る舞いとかのメタな部分は誰が規定するのだろうか？--sumim

なんか、プロトタイプベースも trait とか入れて、だんだんクラスベースに回帰しているらしいです。--sumim

traitって何だっけ？というわけでGoogleって 特色(Trait):プロトタイプからクラスへの逆戻り? 発見 -戯

この本、おもしろそうなんだけどちょっと高いんすよね(^_^;)。--sumim

でも URL 調べてたらむらむらってきて結局 1-Click しちまいました。たった今…＜ばか。--sumim

1-Clickってゆーから、復刊コム(だったっけ?)あたりの投票かと思っちゃいました(笑) -戯

「ClassよりObjectを先に学ぶべし」ってのは正にそうだと思います。Classというもの自体が最適化とROM(半ば不可侵)化の結果みたいな副次的なものだと最近シミジミ思います。

＞OOPの本質を継承だの隠蔽だのと説いたのは何処の誰だ！
ストラウストラップ、というセンが濃厚のようです。--sumim

＞「ClassよりObjectを先に学ぶべし」
まったくもって。Smalltalk でも、分かりにくいクラスやメタクラスな話をひととおり済まさないと先に進めない（学ぶ側からすると進まない）ことには違和感を感じています。しかし、よくよく思い起こすと、インスタンスの説明は最初にしているんですよね。どこでも。なにかメッセージ送信に関する抽象的、比喩的なもので済まされてしまっているのが問題なんでしょうか。どうしたらもっと分かりやすくなりますかね。--sumim

Object感覚の学びにくさの原因 とか考えてみるテスト -戯

オフトピ：世の中にあるクラスに似たもの

クラスと「似た」立場にあるけど微妙に違うものって、たぶん沢山あるよね。
プロトタイプ(雛型?)しかり。例示しかり。イデアしかり。

その中の(ほんの)幾つか(だけ)が、メジャーな言語(この場合はSelfもメジャーだとする(^^;)に
直接実装されてる、っていうだけのことなんだと思う。 --戯

ん？　クラス -が- 何かに似ているのではなく？（と CUE さん風にツッコミ）--sumim

いえ、クラスはクラスで何か1つの概念なのでしょう。(プログラム用に取ってつけたものではなく) --戯

そちらの「クラス」でしたか。失敬、失敬。--sumim

たぶん上のは、CRCカードを書いたときと同じ気分で書いたのだと思われ --戯

つまり、クラスもまた一般語なんだよね。
どこかで(思い出せない：一報歓迎)書いたが、ロールプレイングゲームの人員シートにも「クラス」という欄が有るわけだし、
超ご存知な学校のクラスという言葉も有る。

え？意味が違う？そんなこたぁないんだがなあ？

クラスもオブジェクトも、ついでを言えば多くの Smalltalk 用語、あるいは、その流れをくんでいるとしてよい Mac 用語
（メッセージ、メソッド、ブラウザ、インスペクタ、ワークスペース、トランスクリプト、ウインドウ、メニュー、ボタンなどなど）
はもともとプログラミング言語用語、あるいはコンピュータ用語というわけではなく、
対応する一般語が意味するところや、それらが使用される局面とのアナロジーを意識して
はじめてそれに接する人が親しみやすいよう付けられたもの、ですよね？

ってそういう話じゃなく？(^_^;)--sumim

このページを編集 (15299 bytes)

Congratulations! 以下の 18 ページから参照されています。

This page has been visited 112836 times.