オブジェクト指向の通説

オブジェクト指向は「思想」あるいは「考え方」であり、具体的な方法やプロ グラムの書き方などではありません。だからよく誤解されます。「C++やJava を使うのがオブジェクト指向だ」と言う人は放っておくとしても ^[1]、一見もっともらしい誤解はよく見受けられます。

オブジェクト指向に関する誤解のほとんどは、オブジェクト指向を「プログラ ミングが簡単になる便利な道具」として見ることに起因します。オブジェクト 指向はそんな安っぽいものではなくもっと深遠なものです。そして今まで何回 も繰り返したように、プログラミングが簡単になってもあまり意味はないので す。プログラミングというのはソフトウェアを作るにあたっては重要性の薄い 一工程に過ぎないのですから。

オブジェクト指向は哲学である

オブジェクト指向は「勉強」するものではありません。「理解」するものです。 あるいは「啓示を受ける」ものと言った方がいいかもしれません。 オブジェクト指向はよく宗教のようなものだと言われますが、その通りです ^[2]。オブジェクト指向とは「ものの見方」です。ですから、やり方をうわべだけ 真似ても何の意味もありません。

オブジェクト指向の説明についてよくこんな批判を聞きます。

オブジェクト指向の本では「人間は動物の一種である」とか「人間はご飯を食 べる」とか、およそプログラムとは関係のない説明ばかりが並んでいる。犬も 人間も動物であるということがWindowsのプログラムを組む上で何の関係があ るというのか。

その通り、プログラミングとはまったく関係がないのです。オブジェクト指向 というのは、どうプログラミングするか(how)ではなく、プログラムとは何か (what)にかかわる問題です。ソフトウェアとは何であり、プログラムを組むと いうのは結局どういう作業なのかです。

多くの場合、「ものを作る」という行為は「ものを理解する」という行為 より先に来ます。熱力学の研究の成果によって蒸気機関ができたのではなく、 逆に蒸気機関ができてから熱力学が研究されるようになったのです。人は難し い学問によって対象を理解しなくてもそれを作ることができます。ですから、 オブジェクト指向は「プログラムを作る」という行為に対しては全く関係があ りません。しかし理論をまったく知らないでカンと経験だけでものを作るよ り、対象を理解してからものを作った方が良いものができます。これがオブジェ クト指向を学ぶ意義です。

オブジェクト指向とは、「ソフトウェアとは何か」「概念とは何か」「動作と は何か」といった難しい問題について考えることです。ソフトウェアとは概念 であり知識であり考え方です。「ソフトウェアとは何か」という問いは「知識 とは何か」という問いでもあります。だから「人間はご飯を食べる」とか 「人間は動物の一種である」という例について考えることに意味があるのです。

オブジェクト指向は「哲学」です。ここで「哲学」と言ったのは俗に「経営哲 学」などという言葉で使われるような哲学ではなく、カントやデカルトがやっ たような ^[3] 本物の哲学のことです。そしてこうした哲学というのは教えられるものではな く、自分で考えて答えを見つけることにこそ意義があるものです。

「ソフトウェアっていったい何だろう？」と考えてみてください。そして、そ の問題に答えるという目的意識を持って本を読んでください。「役に立てよう」 という意識では方向を誤ります。

オブジェクト指向と部品化

オブジェクト指向とは、データと操作を一つのまとまり(カプセル)としてとら え、こうした部品の組合せでプログラムを表現することです。

オブジェクト指向についてこのような説明をよく見かけます。この説明は本当 のオブジェクト指向の説明ではありません。構造化手法の説明です。

構造化のことをオブジェクト指向と勘違いしている人がよくいます。それは 構造化手法が皆に理解される前にオブジェクト指向が流行り始めたからです。 そして構造化手法すら知らない人が多数群がり、オブジェクト指向言語で 構造化という概念に初めて触れたからです。C++やJavaなどのオブジェ クト指向言語は構造化手法の考え方の成果を取り入れて作られていますので、 構造化も非常にやりやすくなっています。そしてその「やりやすい部分」がオ ブジェクト指向だと勘違いされてしまったのです。

構造化手法とは「プログラムをわかりやすいまとまりに分割して管理する」と いう考え方のことです。ですから、「まとまり」「分割」という言葉が出た時 点でそれはオブジェクト指向ではなく構造化の考え方です。「部品化」 「モジュール化」「情報隠蔽」「再利用」という言葉も同様です。オブジェクト 指向とは「現実世界に目を向けよ」という考え方の事ですから「部品」とは 何の関係もありませんし、そもそも「プログラム」という言葉が出た時点でそ れはオブジェクト指向の説明として不適切です。

もちろん構造化は非常に重要な考え方であり、あなたがまだそれを知らないな ら是非学ぶべきです。もしあなたが「オブジェクトは部品である」と言われて 「なるほど、それは良さそうなアイデアだ」と思ったなら、あなたはやっと 「構造化手法」の入口に入ったということです。まず構造化手法を勉強し、き ちんと修得して卒業しましょう。オブジェクト指向はそれからでも遅くはあり ません。なぜなら構造化というのはそれだけプログラマにとって意味のあるこ とだからです。

と、ここでは否定的な話をしてしまいましたが、「部品化」という言葉に自律 のニュアンスを含めるなら、オブジェクト指向とは部品化であると言ってもい いでしょう。部品といっても歯車のような受動的な部品を思い浮かべてはいけ ません。モーターのような能動的な部品を思い浮かべるべきです。内部をよく 知らなくてもつなぎさえすれば動くという部品です。

よりニュアンスを引き出そうとするなら、「部品の組み合わせこそがプログラ ムである」と言うべきでしょう。ユーザはただつなげるだけで希望する動作を 実現できるようにするのがオブジェクト指向でいう「部品化」の意義です。

情報隠蔽の罠

オブジェクト指向では「情報隠蔽」というキーワードがよく使われます。この 言葉を使うと、「オブジェクト指向では他人に見せる必要のない情報は隠蔽す るのだ」と思ってしまいます。

確かに間違いではありませんが、考え方が逆です。オブジェクト指向では、 「見せるべきでない情報を隠す」のではありません。基本的に情報はすべて隠 し、「見せないとどうしようもない情報だけを見せる」のです。「情報隠蔽」 ではなく「情報公開」をキーワードにすべきです。

使う側に立って見た時には、必要のない情報を欲しがらないようにしなくては いけません。そのオブジェクトがどう動いているかという情報は必要ありませ ん。あなたが何も知らなくても、ライブラリが勝手にいいように動作してくれ ます。あなたが知らなくてはならないのは、そのライブラリの使い方だけです。

「情報隠蔽」をキーワードにすると、たくさんメソッドを作ってからどれを公 開しようと考えがちです。これはやり方が逆です。外部からオブジェクトを設 定するのに必要なメソッドを用意し、それを公開して、それ以外はすべて非公 開にするようにします。

大事なのは、どう動作させるかということはひとまず置いといて、何を公開す ればいいのか、言い換えればどうユーザに使ってもらうかをまず考えることで す。そしてそれ以外のことはユーザには見せないようにします。情報はわざわ ざ見せない限り隠れているものです。だから考えるべきは「どう隠そうか」で はなく「どう見せようか」になるはずです。

オブジェクト指向は道具ではない

オブジェクト指向は考え方であり、道具ではありません。ですから「オブジェ クト指向を使う」という言葉は(厳密には)間違いです。そして、カプセル化や 継承や多態性といったものも「使う」ものではありません。そこに「ある」も のなのです。

この違いはおわかりでしょうか。これは「発明」と「発見」の違いです。発明 というのは人間が何かを作ることです。それに対して発見というのはずっとそ こにあるものを人間が見つけることです。オブジェクト指向とは現実世界に目 を向けてそこにある構造や法則を見つけ出すことですから、それは発明する ものではなく発見するものです。

例えば、オブジェクトは作るものではなく見つけるものです。例えば「『ウィ ンドウ』をオブジェクトにすればプログラムがすっきり書ける」というのはオ ブジェクトを自分から作り出していること、すなわち発明していることにあた ります。これは考え方が逆です。「あっ、なるほど。『ウィンドウ』というも のがあるんだ。これを軸に考えればわかりやすい」というのが「オブジェクト を発見する」ことです。そして、オブジェクト指向の考え方は前者ではなく後 者です。

発明と発見の違いはかなり微妙です。ニュートンは引力を「発見」したといわ れていますが、別の考え方をすれば引力という概念を「発明」したとしたと言 えるかもしれません。しかし蒸気機関はそれらが発明される前には何もなかっ たのに対し、引力はニュートン以前からずっと存在しました ^[4] 。だから蒸気機関は発明であって引力は発見なのです。たとえ後の人が万有引 力の法則というものを星の運行を計算する道具としてしか使わなかったとして も、法則それ自体は道具ではありません。

オブジェクトも同様です。「ウィンドウ」というものもあなたが考え出したも のではなく、あなたが「ウィンドウをオブジェクトにしよう」と言い出す前か らずっと存在していたものです。だからこれは発見です。あなたは「コンピュー タの画面には枠で囲まれたいくつもの四角形が存在する」ということを発見し、 それを「ウィンドウ」と名付けたのです。同様に「ウィンドウの一種に、閉じ るまで他のウィンドウの操作ができなくなる特殊なウィンドウがある」という ことを見つけ、それを「ダイアログ」と名付けるのです。このように、継承も 作り出すものではなく見つけるものです。

オブジェクトを「作り出そう」と考える人はインチキ科学者に似ています。彼 らは自分が正しいと思い込んでいる事が証明されるように法則を「作り上げよ う」とします。法則というのは「作られる」ものではありません。対象を細か く観察し、あれこれ考えることによって「見えてくる」ものなのです。

オブジェクト指向に不向きなもの

オブジェクト指向のよくある失敗の一つに、何がなんでもオブジェクト指向を 適用しようとしてしまうことがあります。オブジェクト指向とは、「実世界の 現象を説明する」ための試みです。ですから、実世界の現象が簡単に説明でき てしまうようなソフトウェアはオブジェクト指向には向きません。

「オブジェクト指向には向かない」と言うより、「オブジェクト指向はごく一 部の助けにしかならない」と言った方がより正確でしょう。オブジェクト指向 を使うと、「対象がどうであるか」をコンピュータ内部に再現できます。しか し「どうすればいいか」はオブジェクト指向とは無関係です。この部分は従来 の方法で考えなくてはいけません。

オブジェクト指向がやりやすいのはデータベースやGUI、表示系などのソフト ウェアです。これらはまさに「対象がどうであるか」というのを記録したり見 せたりするソフトウェアです。それに対して、判断や思考、制御といったソフ トウェアはオブジェクト指向ではやりにくい対象です。例えば、将棋を指すソ フトを考えてみてください。オブジェクト指向によって、駒がどこにあり、そ れぞれがどういう動きをするかは表現することができます。しかし、それでど ういう手を打てばいいのかというのはわかりません。将棋とは何かというのを 知ることと、将棋でどんな手を打てばいいかということはまた違います。

一つの方法は、「思考」についてオブジェクト指向で考えてみることです。つ まり「将棋で次の一手を考える」というのはどんなことかを考えるのです。す ると「可能な手」とか「その手を打った時の展開」といったオブジェクトで表 現できるでしょう。これは将棋に限ったことではなく、囲碁でもチェスでもオ セロでも同じモデル化になります。つまり、「思考」について考えることは対 象について考えることとは別次元の話であり、対象に対して一段抽象的なレベ ルでものを考えることになります。

この落し穴に多くの人がはまります。「どうすればいいか」をオブジェクト指 向で考えるということは、「『どうすればいいか』をどう表現すればいいか」 という問題を考えるということです。そしてその答えは例えば「C言語の文法」 になってしまいます。答がわかったところでそれは表現のしかたがわかった だけで、どうすればいいかという根本問題は解決しないのです。

オブジェクト指向がGUIに向いているのは、判断は人間にまかせるからです。 自分で判断をするソフトではその判断部分はオブジェクト指向では書けませ ん。判断部分も無理にオブジェクト指向で書こうとしても出来てくるのは 「判断部分はどう書けばいいか」であって、判断部分そのものではありません。

「もの」について考える

オブジェクト指向とは「もの」について考えることです。how(どのように) ではなくwhat(何か)を考えることです。今まではプログラムを作る時にhow(ど のように動くか)だけしか考えずwhat(それは何か)をないがしろにしてきまし た。つまり、それが何かもわからずただ作ってみただけの状態です。水を沸騰 させて蒸気でものを動かす機械はできたけれどそれがなぜどういう原理で動く のかはわからない状態です。

「プログラムをどう作ればいいか？」ではなく「プログラムとは何か？」と自 分に問うてみてください。それは作るものではなく見えてくるものです。そし てそれを考えることこそがオブジェクト指向です。