プロトタイプベース・オブジェクト指向
prototype-based object oriented 。
オブジェクトがスロット(クラスのインスタンスならインスタンス変数やメソッドに相当)の追加をクラスに依存せずに自由にできることを前提としたオブジェクト指向。あるいはそうしたオブジェクトを用いたプログラミングや、それをサポートする機構。
「インスタンスベース」、「オブジェクトベース」とも。 これらへの言い換えは「プロトタイプベース」という言葉が持つ限定的なニュアンスを払拭するのにおおいに役立つ。しかし同時に、前者の「インスタンスベース」において特に、“プロトタイプベースにはクラスがない”あるいは“プロトタイプベースはクラスベースの対極にある(あるいはアンチテーゼである)”といったような教科書的記述に惑わされている人をひどく混乱させるらしく、極端な拒絶反応を示す人もいるので注意。また、後者においては、オブジェクトオリエンテッド=オブジェクト指向と混同されてしまう危険を伴うので、実際に言い換える際には事前の但し書きなど、ある程度のコンセンサスが必要だろう。
「プロトタイプベース」という名称は、クラスでの定義の具体例(インスタンス)としてオブジェクトを生み出すのではなく、既存のオブジェクトの複製(クローン、コピー)、あるいは、それへの参照を持つことですべてを委譲するオブジェクト(チャイルド、シャローコピー)を生み出す手法を意識して作られた。しかし、このようなオブジェクト生成の手順は、本パラダイムにおいてそうすることが可能な“あえてクラスを排除した場合”に際立つ特徴にすぎず、けっして本質ではない(つまり、クラスがあって、クラスのインスタンスとして生成されたオブジェクトであっても、インスタンスベースのオブジェクトであり得る)。
--sumim
言語や環境
- SELF
プロトタイプベースの源流
- NewtonScript
Self を参考に作られた Newton OS の環境構築、データ記述用言語
- Slate
Self, CLOS, Smalltalkをベースにしたスクリプト言語。
- Io
NewtonScript に影響を受けて作られた汎用スクリプト言語
- シンプルで面白そう、とちょっと思った --戯
- 適度な知識がついてきて、よくよく見ればなかなか刺激的。
- soopy
ネームスペースが楽しい言語
- LENS
- ドリトル
教育用日本語プログラミング言語 --戯
- JavaScript, JScript, ECMAScript
- Prothon
Python ライクな文法
- その他、プロトタイプベース言語の一覧 …… http://www.dekorte.com/Proto/Chart.html
- UNIX のファイルシステムにも似たような機構(委譲リンク)を持つものがある。
- Ruby のオブジェクトもプロトタイプベースの素養をもっている。
- 属性はクラスによって与えることは出来ず、実行の文脈でsetされた瞬間に存在し始めることになる。
- メソッドはクラスで与えることも出来るが、インスタンス個別につけてあげることも出来る。後者を「特異メソッド」と呼ぶ。
- クラスメソッドは、クラスオブジェクトの特異メソッドである。構文上もそういう書き方である。このやり方に慣れてしまうと、他の言語でのクラスメソッドを記述するやり方が、至極奇妙に思えるようになってしまう。ここらがプロトタイプベース"志向"を顕著に感じる所。
--戯
- Squeak eToys
原則としてクラスベースだが、オブジェクトが独自のメソッドを持てること、(見かけ上の)クラスを比較的自由に変えられる点ではプロトタイプベースに近い機構や柔軟性を持つ。インスタンス同士をシブリング(兄弟)と呼合う関係にするなど、背後に存在するクラスを意識させない配慮もなされている(にも関わらず、インスタンス変数とかいう用語を UI で平気で使う場面もあり少々分裂症気味なところもあり)。
- Squeak の代名詞的に使われる Squeak eToys ですが、これはあくまで Squeak 環境で使える言語 (言語で語弊があれば、ビジュアルプログラミング環境、あるいは Squeak 上に構築されたアプリ) のひとつに過ぎません。Squeak 環境でネイティブな Smalltalk 言語とは関係ないので念のため。つまり、Squeak 環境の Smalltalk 言語やそのオブジェクト自体には、なんらプロトタイプベースの素養は追加されていません。ちなみに、Squeak 環境の Smalltalk 言語は、最新の VisualWorks 環境のそれに比べれば、いにしえの Smalltalk-80 環境時代の Smalltalk 言語に近いです。(というより「それ、そのもの」)
- Smalltalk 言語と異なり、Squeak eToys においてその変数は型を持ち、また、言語としてのそれは(メッセージ送信メタファの観点からも、通常の「すべてがオブジェクト」の意味でも)純粋オブジェクト指向ではありません。
- Squeak eToys のスクリプトは内部的に Smalltalk 言語に(ひいてはバイトコードに)変換されます。
--sumim
- CLOS
EQL スペシャライザというオプションを使用することで、総称関数に登録された特定のメソッドをあるオブジェクト特異的なものにすることができる。このインスタンス特異的なメソッドの存在は、Ruby の特異メソッドに影響を与えたとされる。
- もっとも、CLOS は Simula に端を発する(C++ など)の抽象データ型の転換型であるオブジェクト指向や、その変種である Smalltalk のメッセージ送信メタファのオブジェクト指向のそれとは一線を画す、Lisp の関数的な側面を活かした独自のオブジェクトモデルを採用しており、そもそも通常のメソッドであってもクラスからは独立した単なる関数に過ぎない(クラスで定義するのは継承元とスロットだけ)。このため、オブジェクトが(クラスを介さずに)メソッドを持つことができる…というクラスベース・オブジェクトに対するプロトタイプベースの特色の意味するところからは、もともとちょっと離れた位置にある。
--sumim
関連
--sumim
クローンとチャイルド
プロトタイプベースのシステムにおいて、オブジェクトは“プロトタイプ”と指定した別のオブジェクトの仕様を、そのクローンあるいはチャイルドとして生じることで継承する(なお、クラスベースにおけるインスタンスとクラスの関係もこれと同種であるとの解釈が可能)。初期状態のチャイルドはすべてをペアレント(プロトタイプ)に委譲する。その後、独自のメソッドスロット(クラスベースでいうところの、インスタンスメソッド)や値スロット(同、インスタンス変数)を持てば差分となる。チャイルドの場合、プロトタイプと重複するメソッドやインスタンス変数を持てばオーバーライドとなる。
実手続きとしてチャイルドを作るときに clone(あるいは clone() )を使用できるものと、clone は copy(shallow copy)と同義で、単にプロトタイプの複製を作るだけのものがありまぎらわしい。実は Io を除き、ほとんどの言語は後者で、むしろこのほうが一般的。つまり、我々が一般にイメージするクローン(じつはチャイルド)を clone で作ることはできない。ちなみに後者に属する言語で“チャイルド−ペアレント”関係を構築するには、スロットを持たない“始原オブジェクト”に委譲用の特殊なスロットを明示的に宣言し、そこにプロトタイプを束縛する作業が必要になる。
プロトタイプベースオブジェクトの柔軟性
プロトタイプベースでいいなぁと思うのは、クラスだとクラスAのインスタンスはクラスBのインスタンスには成り得ないけど、プロトタイプベースなら簡単にできてしまう…ということですね。ま、そもそもオブジェクトがクラスに属していないから当たり前っちゃあ当たり前ですが(^_^;)。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(半ば不可侵)化の結果みたいな副次的なものだと最近シミジミ思います。
- ここ(=ClassはさておいてObjectそのもの)が判らないと、OOP未満世界の"Module"と"Object"の違いが、いつまでたっても理解出来ないんですよね。 -戯
- "Object指向の"解説文の、なんと多くが、Class指向の説明しかしていないことか!
- OOPの本質を継承だの隠蔽だのと説いたのは何処の誰だ!
- 憂鬱本 は大好きなんですが、これも説明がクラスベースに終始してるのが口惜しい。
>OOPの本質を継承だの隠蔽だのと説いたのは何処の誰だ!
ストラウストラップ、というセンが濃厚のようです。--sumim
>「ClassよりObjectを先に学ぶべし」
まったくもって。Smalltalk でも、分かりにくいクラスやメタクラスな話をひととおり済まさないと先に進めない(学ぶ側からすると進まない)ことには違和感を感じています。しかし、よくよく思い起こすと、インスタンスの説明は最初にしているんですよね。どこでも。なにかメッセージ送信に関する抽象的、比喩的なもので済まされてしまっているのが問題なんでしょうか。どうしたらもっと分かりやすくなりますかね。--sumim
Object感覚の学びにくさの原因 とか考えてみるテスト -戯
オフトピ:世の中にあるクラスに似たもの
クラスと「似た」立場にあるけど微妙に違うものって、たぶん沢山あるよね。
プロトタイプ(雛型?)しかり。例示しかり。イデアしかり。
その中の(ほんの)幾つか(だけ)が、メジャーな言語(この場合はSelfもメジャーだとする(^^;)に
直接実装されてる、っていうだけのことなんだと思う。 --戯
ん? クラス -が- 何かに似ているのではなく?(と CUE さん風にツッコミ)--sumim
いえ、クラスはクラスで何か1つの概念なのでしょう。(プログラム用に取ってつけたものではなく) --戯
そちらの「クラス」でしたか。失敬、失敬。--sumim
たぶん上のは、CRCカードを書いたときと同じ気分で書いたのだと思われ --戯
つまり、クラスもまた一般語なんだよね。
どこかで(思い出せない:一報歓迎)書いたが、ロールプレイングゲームの人員シートにも「クラス」という欄が有るわけだし、
超ご存知な学校のクラスという言葉も有る。
え?意味が違う?そんなこたぁないんだがなあ?
クラスもオブジェクトも、ついでを言えば多くの Smalltalk 用語、あるいは、その流れをくんでいるとしてよい Mac 用語
(メッセージ、メソッド、ブラウザ、インスペクタ、ワークスペース、トランスクリプト、ウインドウ、メニュー、ボタンなどなど)
はもともとプログラミング言語用語、あるいはコンピュータ用語というわけではなく、
対応する一般語が意味するところや、それらが使用される局面とのアナロジーを意識して
はじめてそれに接する人が親しみやすいよう付けられたもの、ですよね?
ってそういう話じゃなく?(^_^;)--sumim
このページを編集 (15299 bytes)
|
以下の 18 ページから参照されています。 |
- SELF 最終更新: 2004-07-04, 17:09:53 <m202>
- オブジェクト指向の表現流儀 最終更新: 2003-04-08, 12:54:06 <tibook>
- クラスベース・オブジェクト指向 最終更新: 2003-02-21, 13:37:57 <tibook>
- ドリトル 最終更新: 2004-10-28, 19:47:06 <tibook>
- 戯 最終更新: 2003-11-23, 13:37:47 <airh128>
- Object感覚の学びにくさの原因 最終更新: 2004-08-31, 14:04:48 <apollon>
- JavaScript 最終更新: 2004-09-03, 11:20:06 <p2035-f>
- CUE 最終更新: 2005-02-12, 10:31:36 <61-27-3>
- NewtonScript 最終更新: 2004-09-28, 01:34:05 <192>
- クラス指向 最終更新: 2013-11-26, 21:26:01 <fl1-125>
- HyperTalkとプロトタイプベース 最終更新: 2004-12-04, 16:46:06 <adsl-22>
- クラス 最終更新: 2004-05-11, 09:18:42 <bullsey>
- Io 最終更新: 2016-03-18, 11:34:49 <phara2>
- Traits 最終更新: 2015-11-05, 09:24:48 <phara2>
- 特異メソッド 最終更新: 2006-04-29, 10:32:23 <p4234-i>
- Soopy 最終更新: 2005-07-10, 00:59:10 <192>
- Slate 最終更新: 2006-04-26, 10:34:16 <khp0591>
- PMD 最終更新: 2006-05-30, 20:09:53 <khp0591>
This page has been visited 112848 times.