第 9 版に加えられた変更
削除は 取消線 、追加は 太字 で示されます。段落の一部が修正されたときは、その段落全体をいったん削除して、新しい内容の段落を追加したように表現されます。
すべてがオブジェクト
Everything is an Object.
本来は、アラン・ケイの*メッセージングのオブジェクト指向>メッセージ指向*を徹底した際に必然的に導かれる要件だったが、メッセージングの意図するところの形骸化により一人歩きし、*オブジェクト指向言語の「純粋性」*をはかる基準となっているもの。言語内のエンティティが、ある一定以上オブジェクトであれば「すべてがオブジェクト」であり、「純粋」であると名乗ることが許されるらしい。
本来は、アラン・ケイの*メッセージングのオブジェクト指向>メッセージ指向*を徹底したシステムを構築した際に必然的に導かれる要件だったが、メッセージングの意図するところの形骸化により一人歩きし、*オブジェクト指向言語の「純粋性」*をはかる基準となっているもの。言語内の基本型やエンティティが、ある一定以上オブジェクトであれば「すべてがオブジェクト」であり、「純粋」であると名乗ることが許されるらしい。
_
メッセージングのオブジェクト指向では、メッセージングを介してシステムに動的性を持たせることを目指すが、このメッセージの受け手（レシーバ）として通常「オブジェクト」を用いる。余談だが、アラン・ケイがメッセージングのオブジェクト指向を発案する際のヒントとなった生命では、メッセージの受け手は、核酸であったり、蛋白質であったり、マクロに見れば細胞であったりする。
メッセージングのオブジェクト指向では、メッセージングを介してシステムに動的性を持たせることを目指すが、このメッセージの受け手（レシーバ）として通常「オブジェクト」を用いる。余談だが、アラン・ケイがメッセージングのオブジェクト指向を発想する際のヒントとなった生命では、メッセージの受け手は、核酸であったり、蛋白質であったり、マクロに見れば細胞であったりする。
つまり、多くのことをメッセージングで表現しようとすると、必然的にシステムの構成要素はレシーバで満たされることになり、結果的にユーザーの目につく（つまりユーザーが操作可能な）エンティティはオブジェクトでなければ不自然になる。たとえば、Smalltalk では 3 + 4 のような二項演算も、条件分岐も、メッセージングで行なう（*フリをしている>メッセージングで行なう「フリ」もしている Smalltalk*）が、このためには + 4 や ifTrue: [#doSomething] といったメッセージの受け手である数値（3）や真偽値（true もしくは false）もオブジェクトでなければならない。
このとき「オブジェクト」はもはや、SIMULA からの借り物であるオブジェクト（つまり、クラスのインスタンス）ではなく、メッセージの受け手として規定されるべきものと考えた方がよいだろう。ところが、メッセージングパラダイムによらない現在主流のオブジェクト指向言語（たとえば Java など）においてもこの「すべてがオブジェクト」という考え方がもちだされ、無用な言語間宗教戦争の火種になることは悲しいことである。
念のため。メッセージングのオブジェクト指向に立脚しない、つまり、*ユーザー定義型のオブジェクト指向>クラス指向*に軸足を置くオブジェクト指向言語においては、基本型がユーザー定義型（つまりクラス）であったり、クラスがまた別のクラスのインスタンスである必然性は、メッセージングを介した動的性をキモとする Smalltalk のようなシステムほどには、ない。ユーザー定義型のオブジェクト指向に属する言語では、むしろ逆で、ユーザー定義型に属するデータ、つまり、クラスのインスタンスであるオブジェクトが、基本型と同じように違和感なく扱えることのほうが重視されるべきであろう。
なお、オブジェクト指向言語の純粋性については、ここで述べた「すべてがオブジェクト」であることとは別に、設計当初からオブジェクト指向を意識したものであったか？という基準も存在するようdが、これはまた別の話。
なお、オブジェクト指向言語の純粋性については、ここで述べた「すべてがオブジェクト」であることとは別に、設計当初からオブジェクト指向を意識したものであったか？という基準も存在するようだが、これはまた別の話。
ここまで --sumim
_
+%_-@