“オブジェクト指向”の本質

「OO(OOP)とは何か?」については、ネタが割れてしまえばそんなに複雑なものではない…と個人的には最近、考えるようになってきています。

  • リスコフのユーザー定義型(aka、抽象データ型。データと手続きのセット)そのもの、あるいはその「ユーザー定義型」をクラスやそれに準ずる機能で実現しようとするOO(ストラウストラップ。aka、クラス指向。継承を使ったプログラミング)。もしくはそれらを一般化したOO(クック。aka、手続きによる抽象化)。
  • メッセージングにより動的性を実現しようとするOO(ケイ。aka メッセージ指向)
  • 今回登場した、後者のメッセージングのOOのミニマリズムをおしすすめることによって派生的に生じたOO(アンガーとスミスからの 派生 変形。aka、プロトタイプベースOO。フレームとスロット、あとは委譲機構があれば十分…というミニマル化の結果、アンガーとスミスの頃には重要だった“メッセージング”というコンセプトすらそぎ落とされたのは興味深いですね!)。

この三系統のOO、各々の本質を把握できていれば、それらの混成ということで、ほとんどのOOPLの機能や立ち位置、世にはびこる“俺OOP”の中身…はスッキリ説明できるはずです。

http://d.hatena.ne.jp/sumim/20080413/p1#c1208228975


ということで、これら三系統のOOにおけるそれぞれの本質を、ざっくりとですがまとめてみました。前にもなんだか 似たようなこと&今回と矛盾するようなこと を書いたような気がしますが大人の対応をお願いします(^_^;)。

今回は、よりシンプルに「なには無くとも、これだけは欠いてはいけないもの」を。そして何かと話題となっていて、個人的にも最近、理解の整理をつけることができたプロトタイプベースOOも加えてより網羅的に。


▼データ型にこだわるOO

この系統のOOの本質は、とにかく言語のユーザー(プログラマ)が「データ型」を定義できること。その先の、型安全なプログラミングが真の目的です。実装としては、ユーザー定義型を実現するのにクラスやそれに準ずるもの(抽象クラスやインターフェイス)を使うのが主流。継承がないとダメ、とか、手続き(関数、メソッド)は型に内包されないとダメ、とか、情報隠蔽・アクセスコントロールがないとダメ、とか、いろいろと流派があるけれど、それらは(各々の流派にとってはそうだとしても…)総じては“本質”とよべるほどのものではない“おまけ”。とはいえ「郷に入っては郷に従え」。たとえ“おまけ”でも各流派の教えやしきたりにはきちんと従うべきでしょう。


▼メッセージングにこだわるOO

この系統のOOの本質は、プログラムやそれを実行する処理系を含め、世の中のいろんなコトをメッセージングとそれの受け手の振る舞いに置き換えてみよう…という考え方それ自体。その先の、あらゆる切り口で動的なシステムの設計と実現が真の目的です。目的はともかく、メッセージングというお題目自体はパワフルで、意外なものにまで適用できるうえ、たんなる解釈ともとれるので、関係ないところ(たとえば他の二系統のOO)に対する汚染力も最強最悪です(でも、慣れれば排除も簡単w)。実装のバリエーションもいろいろで、主流は仮想関数もどき。動的結合っぽいことができれば、実はなんでもOK? 文法レベルにまでこだわりを持ち込むケースも有りますが、これは“おまけ”で本質ではありません。


▼オブジェクトと委譲のみからなるOO

この系統のOOの本質は、オブジェクトが自由にスロット(データや手続き)を持てること。スロットの追加や削除は、動的(実行時)に行えるにこしたことはありませんが、動的であることそれ自体は本質ではありません。実装上は、「スロット」とそれを束ねた「フレーム」(つまり、オブジェクト)、それとあと、存在しないスロットに対するアクセス時に発動できる「移譲」のための何らかの機構があればすべて事足りる…という考え方。その先の、目的や思想はとくに見えてきません。強いて言えば、シンプリシティを貫くことでの前二者に対するアンチテーゼ…でしょうか。