ラベル オブジェクト指向 の投稿を表示しています。 すべての投稿を表示
ラベル オブジェクト指向 の投稿を表示しています。 すべての投稿を表示

2012/06/16

何も隠されてはいない

こんにちは、あまりにも更新が少ないんで、そろそろこのブログも存在を忘れられつつあるのではと憂慮している@tomoodaです。 今日のダベりネタは情報隠蔽です。

オブジェクト指向といえば情報隠蔽によるモジュール化という説明を見かけるたびに、「オブジェクト指向は何も隠してなんていないのに」と思ったりします。 以前、クラス/インスタンス関係と型/値関係をゆる~くしてみようで、オブジェクト指向は分類学じゃないよ、クラスはオブジェクトを分類するんじゃなくて、振る舞いを分類しているだけなんだよー、とか書いてみました。 まあオレが言うことだからあんまり信憑性ないかもしんないけど、情報隠蔽についてもなんだか誤解が多いなあと思ってます。

まずは、クラスはインスタンスの分類じゃなくて振る舞いの分類なんだよ、を振り返ってみましょう。

例えば、悪名高い、動物の例。動物クラスと犬クラスと猫クラスがあります。 これらのクラスは個々の動物を犬とか猫とか動物に分類するんじゃないんです。 個々の動物の色々な振る舞いを列挙してみましょう。 散歩したり、マーキングしたり、ブロック塀に上ったり、フリスビーをくわえたり。 これらの振る舞いを、これは犬の振る舞い、これは猫の振る舞い、これは動物一般の振る舞い、と分類するんです。 それがクラスだと思うのです。

単に振る舞いをまとめただけだから、分類学じみたことなんて必要ないです。実装上の便宜で適当に決めていけばいいです。 実装継承バンザイ。いいんですよ、それで。

こう書くと、多くの人は「クラスが定義するメソッド(メンバ関数)はそうかもしれないけど、インスタンス変数(メンバ変数)はどうすんだ?あれはオブジェクトの構造を定義しているんじゃないのか?クラスがインスタンスの構造を定義しているんなら、クラスはインスタンスを分類しているんじゃないか!」と思うかもしれません。

ブッポ〜ン

まあ正当派のソフトウェア工学では、クラスはオブジェクトの構造を定義すると教えています。 そしてその根拠が抽象データ型です。 抽象データ型は値が持つデータ構造を手続き抽象によって隠蔽するという機構ですが、多くのソフトウェア工学の本ではオブジェクトは抽象データ型の実装の1つであると見なしているようです。

でも、残念ながら、オレオレオブジェクト指向では、オブジェクトは抽象データ型の実装ではありません。 全くの別物です。 では、クラスで定義するインスタンス変数(メンバ変数)が、抽象データ型で隠蔽されるデータ構造ではないのなら、一体何なんなんでしょう。

それは「振る舞いを実現する環境」です。 ここで言う環境というのは、クロージャに近いです。ネストした内側のクロージャが外側のクロージャのローカル変数を参照するようなものです。 別にオブジェクトのデータ構造とかじゃなくて、オブジェクトの振る舞いを実現するメソッドを実装するための環境なんです。

そう考えると、クラスというのはオブジェクトの振る舞いを分類して定義しているだけの話で、分類学的な整合性とかどうでもいいし、データ構造を隠すとかはどうでも良い話なのです。 オブジェクトの本質は、ユーザが認識した対象を捕まえて、そいつにメッセージを送って、そいつがメッセージに対して何らかの振る舞いをすることです。 つまり、データ構造を隠すも何も、データなんて最初からオブジェクト自身にとってはどうでもいいことで、大事なのはその振る舞いなのです。

つまり、オブジェクトは何も隠してなんていません。 少なくともSmalltalkでは。

次に、Smalltalkでは何も隠されていないどころか、全てが表現されるという話をします。

Smalltalkでは全てがオブジェクトだと言われていますが、実は、Smalltalkでもっと大事なのは、全てが評価可能な式として表現されることなのです。 これこそがSmalltalkをSmalltalkたらしめている所以です。

Smalltalkの素晴らしさは、そのダイナミズムにあります。できるかぎりあらゆる事が動的に決まります。 アラン・ケイ博士がいうところの「あらゆる事の、極限までの遅延」です。 そして、Smalltalkでのダイナミズム、すなわちワークスペースでの表現式評価も、クラス定義も、メソッド定義も、全ては「評価可能な式」として表現されます。 Smalltalk内で発生したダイナミズムは「評価可能な式」として表現され、記録され、そして実行されます。 「あらゆる事の、極限までの遅延」があるから、記録されたダイナミズムは再実行が可能になります。 そして記録されたダイナミズムがSmalltalk環境の再構築を可能にし、記録されたダイナミズムを別の環境で再実行することを可能にし、さらなるダイナミズムを生み出します。

どうですか? 本来のオブジェクト指向では「何も隠されていない」のです。 なぜなら、プログラマに全てを曝け出し、全てを分解することができ、全てを変更することができることこそがオブジェクト指向が本来目指しているプログラミングだからです。

つまり、隠したいプログラムがあったらオブジェクト指向言語はお勧めしません、というのが今日の結論です。ツ

2011/09/17

オブジェクト指向って何?

オブジェクト指向という言葉が陳腐化して、もうずいぶん時間が経ちましたね。 もうオブジェクト指向は終わった、とか、色々な事が言われています。 オブジェクト指向は本当に終わったんでしょうか?

残念でした。オレにとっては、オブジェクト指向ってのは、これから愉快痛快な展開で面白くなってくるコンセプト。ツ 皆が「終わった」と言っているのは、オブジェクト指向を実現するために使えそうな数多くの技術のうち、 とりあえずということで仮採用したプログラム構成技術の1つにすぎないと思うのです。

さて、では本題。オブジェクト指向って何?

オブジェクト指向とは、計算メディアを使っている人が認識したモノに対してプログラミングをすること、だと思っています。 例えば、このブログに表示されている著者近影のイラスト。眼鏡をかけているのに気付いたでしょうか? 今、あなたは、イラスト中の眼鏡を認識しました。この眼鏡に対して、「レンズの色はヴィヴィッドピンクがいいな。」というメッセージを送って、眼鏡がそのメッセージを受け取って、レンズの色をヴィヴィッドピンクにするのがオブジェクト指向です。

「おいおい、それはオブジェクト指向じゃなくてフォトショだろ!」と思う人が多いことは重々承知しています。ツ その上で、あえて、「そうだね、フォトショはオブジェクト指向から多大な影響を受けたし、グラフィカルなUIでオブジェクト指向を実現するには、画像処理とか画像認識は非常に強力な武器だと思うよ。」と答えます。

つまり、オブジェクト指向というのは、

  1. 人間が何かを認識する。
  2. その「何か」を掴む。
  3. 掴んだ「何か」にメッセージを送る。
  4. 「何か」がメッセージを受け取る。
  5. メッセージに応じて、「何か」が何かをする。
という一連のプロセスから成っています。

一方、巷で「終わった」と言われているオブジェクト指向とは何でしょうか? 情報工学系の技術書ではよく、オブジェクト指向=継承カプセル化多態、とか言われたりしますね。 で、クラスベースオブジェクト指向ではクラス階層を使って、プロトタイプベースオブジェクト指向では委譲連鎖を使います。 でも、これって、上に挙げたオブジェクト指向のプロセスの後半だけの話です。

オブジェクト指向の技術書ではまず必ず、メソッドについて言及がありますが、これすらオブジェクト指向そのものにとっては本質ではありません。 受け取ったメッセージに対応するメソッドを探索することは、とりあえず採用している仮の仕組みに過ぎません。 現にSmalltalkRubyでは対応するメソッドが無くても、対応する処理を記述することができます。

これからオブジェクト指向を本格的に実現していくためには、むしろ前半の仕組みが必要です。 ボタンを押したらダイアログが開く、とか、変数で掴まえた「オブジェクト」にメッセージを投げる、で満足するのは20世紀で卒業しなくっちゃ。ツ 21世紀のオブジェクト指向は、もっと人間の認知に迫ることが必要なんです。 人間が注目している対象を「掴む」ための、入力デバイスや画像認識や自然言語処理や音響認識が必要です。 そして、「掴んだ」対象にメッセージを送るための、インターフェイス上の「言語デザイン」が必要です。 そろそろAltoを越えましょうよ。

オブジェクト指向の研究開発の軸足は、ソフトウェア工学から認知科学言語学機械学習インタラクションデザインに移っていきます。 どうです?オレはワクワクドキドキが止まりませんよ? ツ