“オブジェクト指向”の本質
「ＯＯ（ＯＯＰ）とは何か？」については、ネタが割れてしまえばそんなに複雑なものではない…と個人的には最近、考えるようになってきています。
- リスコフのユーザー定義型（aka、抽象データ型。データと手続きのセット）そのもの、あるいはその「ユーザー定義型」をクラスやそれに準ずる機能で実現しようとするＯＯ（ストラウストラップ。aka、クラス指向。継承を使ったプログラミング）。もしくはそれらを一般化したＯＯ（クック。aka、手続きによる抽象化）。
- メッセージングにより動的性を実現しようとするＯＯ（ケイ。aka メッセージ指向）
- 今回登場した、後者のメッセージングのＯＯのミニマリズムをおしすすめることによって派生的に生じたＯＯ（アンガーとスミスからの
派生変形。aka、プロトタイプベースＯＯ。フレームとスロット、あとは委譲機構があれば十分…というミニマル化の結果、アンガーとスミスの頃には重要だった“メッセージング”というコンセプトすらそぎ落とされたのは興味深いですね！）。この三系統のＯＯ、各々の本質を把握できていれば、それらの混成ということで、ほとんどのＯＯＰＬの機能や立ち位置、世にはびこる“俺ＯＯＰ”の中身…はスッキリ説明できるはずです。
http://d.hatena.ne.jp/sumim/20080413/p1#c1208228975
ということで、これら三系統のＯＯにおけるそれぞれの本質を、ざっくりとですがまとめてみました。前にもなんだか 似たようなこと＆今回と矛盾するようなこと を書いたような気がしますが大人の対応をお願いします(^_^;)。
今回は、よりシンプルに「なには無くとも、これだけは欠いてはいけないもの」を。そして何かと話題となっていて、個人的にも最近、理解の整理をつけることができたプロトタイプベースＯＯも加えてより網羅的に。
▼データ型にこだわるＯＯ
この系統のＯＯの本質は、とにかく言語のユーザー（プログラマ）が「データ型」を定義できること。その先の、型安全なプログラミングが真の目的です。実装としては、ユーザー定義型を実現するのにクラスやそれに準ずるもの（抽象クラスやインターフェイス）を使うのが主流。継承がないとダメ、とか、手続き（関数、メソッド）は型に内包されないとダメ、とか、情報隠蔽・アクセスコントロールがないとダメ、とか、いろいろと流派があるけれど、それらは（各々の流派にとってはそうだとしても…）総じては“本質”とよべるほどのものではない“おまけ”。とはいえ「郷に入っては郷に従え」。たとえ“おまけ”でも各流派の教えやしきたりにはきちんと従うべきでしょう。
▼メッセージングにこだわるＯＯ
この系統のＯＯの本質は、プログラムやそれを実行する処理系を含め、世の中のいろんなコトをメッセージングとそれの受け手の振る舞いに置き換えてみよう…という考え方それ自体。その先の、あらゆる切り口で動的なシステムの設計と実現が真の目的です。目的はともかく、メッセージングというお題目自体はパワフルで、意外なものにまで適用できるうえ、たんなる解釈ともとれるので、関係ないところ（たとえば他の二系統のＯＯ）に対する汚染力も最強最悪です（でも、慣れれば排除も簡単ｗ）。実装のバリエーションもいろいろで、主流は仮想関数もどき。動的結合っぽいことができれば、実はなんでもＯＫ？ 文法レベルにまでこだわりを持ち込むケースも有りますが、これは“おまけ”で本質ではありません。
▼オブジェクトと委譲のみからなるＯＯ
この系統のＯＯの本質は、オブジェクトが自由にスロット（データや手続き）を持てること。スロットの追加や削除は、動的（実行時）に行えるにこしたことはありませんが、動的であることそれ自体は本質ではありません。実装上は、「スロット」とそれを束ねた「フレーム」（つまり、オブジェクト）、それとあと、存在しないスロットに対するアクセス時に発動できる「移譲」のための何らかの機構があればすべて事足りる…という考え方。その先の、目的や思想はとくに見えてきません。強いて言えば、シンプリシティを貫くことでの前二者に対するアンチテーゼ…でしょうか。
