実はそれを「オブジェクト指向」と呼ぶのは誤っているかも知れない。


続・初めてのPerl
-
Perlオブジェクト、リファレンス、モジュール
R.L. Schwartz, T. Phoenix
[原著]
Matzにっき(2006-01-27)
で、私よりも数学的思考法に強そうな小飼さんまで、 そのような「混同」をしてしまうというのは、 単にマーケティング用語として「オブジェクト指向」が使われた不幸だけでなく、 「オブジェクト」という単語が持つ「魔力」というのものは 私の想像以上に強いということなのかもしれない。

以下のケースを考えてみる。

まず、手続き型で、あるファイルの中身を全て出力するPerl5プログラム。

open my $fh, "<", $filename or die "$filename:$!";
while(my $line = <$fh>){
  print STDOUT $line;
}
close $fh;

ここでは$fhは、関数への単なる引数の一つに過ぎない。ただし、「ファイルハンドル」という抽象化はすでになされている。

次に、OOPの例。

use FileHandle;
my $fh = FileHandle->new($filename, "r") or die "$filename:$!";
while(my $line = $fh->getline){
  STDOUT->print($line);
}
undef $fh;

今度は、$fhは単なる引数ではなくオブジェクトであり、関数はメソッドとなっている。それでは引数とオブジェクトの違いは何だろうか?あえて日本語に読み直してみよう。

print STDOUT $line;

は、「STDOUTというファイルハンドルに$lineを出力せよ」と読める。ここでの「主語」は、「実行環境」そのものである。あまりに明白なのでいちいち主語を付けることはしない。これは英語も同様だ。命令形における主語は常に"you"、すなわち「聞き手」である。

これが、OOでは

STDOUT->print($line);

STDOUTよ、$lineを出力しなさい」とこうなる。そう。OOでは主語の指定があるのである。その意味では、「オブジェクト指向」というより「サブジェクト指向」と言った方が正しいかも知れない。

実は構造体というのは、すでに「オブジェクト」ではある。単なる数字の羅列だったものを、人間によりわかりやすいように「抽象化」されているのだから。しかし、この段階ではまだ「オブジェクト」は自分が「何が出来るのか」を知らない。知る必要もない。なぜなら実際に「行う」のは実行環境そのものなのだから。区別するため、私はOO以前の構造体を"inanimate object"と呼びたい。

これに対し、OOにおけるオブジェクトは、単にデータが抽象化されているだけではなく、自分が何が出来るのかを「知っている」。だから記法においても「実行環境」ではなく「オブジェクト」に「頼む」という形を取っている。OOにおけるオブジェクトは"animate object"であり、よってsubjectとなりうる。

これを見れば、本当はオブジェクト指向はサブジェクト指向と呼んだ方が良さそうだが、それが避けられたのはsubjectに「ジコチュー」なニュアンスが含まれていたためだと思われる(subjective は「主観的」という意味)。

確かにこうして抽象化の段階を見ると、「オブジェクト指向は構造化の『次』」ということもわかる。すでに構造化プログラミングにおいても、データは構造体という形で抽象化がなされていたが、「主体」までは抽象化されていなかった。抽象化2.0というわけである。

このことはまた、なぜオブジェクト指向が大規模プログラミングに好んで使われるかの理由の一つでもある。オブジェクト、いやサブジェクトの導入により、「分業」が可能となるからだ。それ以前はデータの抽象化による「分別」まではなされていたが、「主体」が「実行環境」しかなかったため「分業」までは出来なかったのだ。

そして、このことは一行野郎(one-liner)などのプログラムにおいて、オブジェクト指向が好かれない理由ともなりうる。レシピで充分なところに物語の登場人物まで考えるのは面倒、というわけだ。

構造化プログラミング = Abstraction 1.0 によりまず「名詞」が抽象化され、オブジェクト指向プログラミング = Abstraction 2.0 により「主語」が生まれた結果「動詞」が抽象化された今、次の抽象化の対象は何なのだろうか....

Dan the Abstracter