フレームワークの本当の意味：実行可能な知識とソフトウェア（5）

オブジェクト指向のポリモルフィズムは一部の人から「何が起こるか分からない」という理由でひどく嫌われている。われわれソフトウェア・アーキテクトにとって「柔軟につなぐ」ということは、良いことなんだろうか、悪いことなんだろうか（本文より）

　ソフトウェアを作るということは、物事を「分ける」=「分かる」ということである。分け方にはいろいろあるけれど、分けたものを分けたままにしておいても生命を持ったソフトウェアとして動きだすことはない。分けたものは、何とかしてつながなくてはならないのである。分けることを分析（analysis）といい、つなぐことを総合（synthesis）という（こともできる）。

　ソフトウェアを作る場合において、物事を分ける方法には例えば「モジュール」「オブジェクト」「ドメイン」「アスペクト」といったさまざまな方法やレベルがある。そして、その裏には必ず分けたものをつなぐやり方が隠されている。

　分けるやり方に比べ、つなぐやり方をあまり意識することはないかもしれないけれど、実はつなぐ方が格段に難しい。つなぎ方を間違うとフランケンシュタインが創造した怪物のようなものができてしまうかもしれないからだ。だから、つなぐ方の細かいことは、できるだけ人間があれこれ考えなくてもできるように工夫されている。

　モジュールとモジュールをつなぐには「インターフェイス」を使う。インターフェイスを通して別のモジュールを呼び出す。呼び出す仕組みはたいてい、リンカとかローダと呼ばれるツールが面倒を見てくれる。呼び出し先がコンパイル時に静的に決まる場合は、比較的簡単だけれど、Javaのようにネットワーク上の別の場所から（呼び出し先を）探す時間がある場合には、「本当につないでもいいのかどうか」をセキュリティの面からいちいちチェックしなければならない。

　オブジェクトとオブジェクトをつなぐのは「メッセージ交換」だ。モジュールのつなぎ方よりは、少しだけ柔軟性が高い。モジュールをつなぐというのは、“相手を決める”ということだったけれど、オブジェクトの場合にはあまり重要ではない。「行き先はメッセージに聞いてくれ」みたいなところがある。実際、ローカルなオブジェクトにメッセージを送ったつもりだったのに、それはプロキシ（代理人）で、最終的にはリモートのオブジェクトに送られてしまうというのがオブジェクト指向のリモート・メッセージングの基本的な仕組みだ。

　さらに、モジュールの場合には「インターフェイスを通してモジュールのどのサービスを呼び出すか」も最初にほとんど決めてしまうのだけれど、オブジェクトの場合、それを決めるのはメッセージを送った方ではなく、メッセージを受け取った方である。例えば、「図形」オブジェクトに「描け」といっても、「丸」オブジェクトならば丸を描き、「三角」オブジェクトならば三角を描く。いわゆるポリモルフィズムはメッセージを受け取った側の主体性から生まれる。

　オブジェクト指向のポリモルフィズムは一部の人から「何が起こるか分からない」という理由でひどく嫌われている。われわれソフトウェア・アーキテクトにとって「柔軟につなぐ」ということは、良いことなんだろうか、悪いことなんだろうか。

　もちろん、それは状況による。とても小さな世界で、登場人物も限られており、起こる出来事も初めからみんなはっきりと分かっていて、これ以上変化することがないという状況ならば、柔軟性なんてものには出る幕がない。でも、そうでなければ、つまりわれわれの作るソフトウェアが「複雑な世界」ならば、ソフトウェア・アーキテクトやプログラマーがすべてを取り仕切ろうと考えるのはあきらめた方がいいのかもしれない。

　オブジェクトのメッセージ交換の考え方は、すべてを人間が制御するのではなく、「つながれ方」の仕組みをオブジェクトの方に入れておいて、「勝手につながれ」という考え方だ。もっとも、数億年を掛けて進化してきた生物と違い、人間が後知恵で作ったものだから、つながれ方の仕組みを考えるのは大変なんだけれど、どうせ後で大きな苦労するのならば、先に少しだけ苦労しておけ、というわけだ（注）。

　ここまでは1つ1つのモジュールやオブジェクト間のつなぎ方を考えてきたけれど、つなぐためには、そのつなぎ方の「土台」みたいなものがあるともっと便利だ。われわれはこれを「フレームワーク」と呼ぶ。

　EJB（Enterprise Java Beans）なんていうのもフレームワークの1つと考えていいだろう。フレームワークが与えられると、つなぎ方も大体決まってしまう。どうやってつなごうと苦労して考えるまでもなく、「この線とこの線だけは用意しておいてね、後は適当な場所に置いておいてくれれば、適当につながるから」ってなもんである。フレームワークがあればつなぎ方は大体決まってくるから楽といえば楽なのだが、そうなると、すべてがフレームワーク次第ということになってしまう。やたらと長々しい呪文を唱えないとつないでくれないフレームワークとか、少しでも想定していないことをやろうとするとめちゃくちゃ大変なことになるフレームワークとか、フレームワークといいながら結局自分でほとんどつなぎ直す羽目に陥るフレームワークとかいっぱいある（あれとかあれとか……ね。もちろん素晴らしいフレームワークもある）。

　フレームワークを作るのは大変なのである。フレームワークというのはつまり、つなぎ方の集大成といっていい。「こういうものを作るためにはこういう部品をこうやってつなぐとうまくいく」という知識を寄せ集め、それをみんなが使えるようなソフトウェアにしたものがフレームワークだ。「こういうものを作るためにはこういう部品をこうやってつなぐとうまくいく」という質の良い知識がいっぱい集まらないうちに作り始めると、ろくなフレームワークにはならない。「こういうものを作るためにはこういう部品をこうやってつなぐとうまくいく」という質の良い知識がいっぱい集まったものを「パターン・ランゲージ」と呼ぶことは皆さんご存じだろう。いわゆるパターンは自然言語であるパターン言語で記述されたものなのでそのまま「実行可能な知識」ではないけれど、それを「実行可能な知識」にしたものがフレームワークである。フレームワークには大きな資産価値がある。もしあなたのチームが似たようなものを3回目に作ることになったのなら、最初の1カ月をかけていままでの成果をフレームワークにまとめる価値があるかもしれない。

　いままで書いてきたのはオブジェクトならオブジェクトという多くの同じようなものをつなぐ方法だった。でもソフトウェアを作るときには、まったく異なるものをつなぐ必要も出てくる。以前「ドメインに分ける」という話をしたけれども（第3回 「ドメイン・エンジニアリング温故知新」）、ドメインというのは「領土」や「分野」を表しているくらいで1つ1つが大変異なっている。例えば、お風呂の給湯システムを作るとしたら、

• ユーザー・インターフェイスのドメイン
• お風呂のドメイン
• センサーやアクチュエータを制御するドメイン

なんてのがあるわけだ。

　センサーやアクチュエータのドメインは割り込みやイベントが飛び交い、ポートにバイトを読み書きする物理レベルの世界で、その世界では「快適な湯温」なんて概念は存在しない。一方、お風呂のドメインでは湯温を快適に保つとか、熱過ぎてやけどしないようにするのが重要で、どのアドレスにどの値を書き込むと何が起きるかなんてことは知るよしもない。それぞれのドメインが自分の仕事を精いっぱいこなしているのだが、やっぱりどこかでほかのドメインの助けが必要になる。この「異なる世界や言葉」をつなぐ通訳の役割をするのが、「ブリッジ」だ。

　ブリッジは自分で何かをするわけではないけれど、あるドメインからの要求を別のドメインに理解可能な言葉に訳して伝える。つまりブリッジは単に何かを伝えるだけではなく、知識から知識への変換を行うことによってつなぐ仕掛けということになる。そしてわれわれは、ソフトウェアの構築作業を「知識変換過程」であると主張しているのだから、ブリッジに相当するものはとても重要な役割を果たしている、と認識しなければならない。しかし、その話はまた別の機会に。

　人生いろいろ、つなぎ方いろいろ。