 |
| 図5●オブジェクトの粒度 本来オブジェクト指向の観点に立てば，すべてをオブジェクトとして考える（a）。しかし，大きく分かりやすいものだけをオブジェクトとして抽出して，粒度の大きいオブジェクトとする考え方もある（b）。その後詳細化するときに，オブジェクトで作るか手続き的に作るかは別問題となる。 |
何が何でもオブジェクト，なのか
オブジェクト指向のメリットの一つとしてよく言われるのが，現実に近いモデルを作成しやすい点である。これについてもこの連載で説明してきたが，一方で目に見えないものをオブジェクトとして抽出するのは意外に大変である。ここもオブジェクト指向を難しくしている原因の一つだろう。
何が何でもオブジェクトで構成しようとすれば，目に見えないモノもオブジェクトにしなければならない。確かにオブジェクトとして作っておけば，後々再利用しやすくなる可能性はある。だがオブジェクト指向の分かりやすさを設計時点で生かすならば，ここに敢えて目をつぶるという選択肢もあり得る（図5[拡大表示]）。前述のように，オブジェクトは分割統治の単位である。適切な大きさに分割されていれば，分割した中は必ずしもオブジェクトで構成されていなくてもよい。
ネットワークに分散配置させる
むしろ，分割する機能単位として識別することを重視した方がよいのかもしれない。例えばシステムのパーティショニングを考えたとき，オブジェクト指向の考え方は非常に便利である。まとまったコンポーネント単位で，システムをネットワーク上に分散させることができる。
これを実現するための規約がCORBA（Common Object Request Broker Architecture）である。CORBAはRPC（remote procedure call：リモート手続き呼び出し）をオブジェクト指向モデルに拡張したものである。ネットワークに接続した別のコンピュータで動作するプログラムの呼び出しを，通常のメソッド呼び出しと同じ形で記述できる。RPCではプログラム作成時に所在地を管理しなければならないが，CORBAを使えばプログラマはほとんど所在地を意識しなくて済む。
CORBAは，サーバーの所在地を管理する機構を備えている（図6[拡大表示]）。このためサーバー・オブジェクトの所在地をクライアント側で関知する必要がなく，例えばサーバー機能を置き換えたりする場合などに有効である。結果としてシステムの柔軟性を高めることができる。
CORBAの特徴は異機種間通信や，開発言語を問わないことだろう。アプリケーション・サーバーのインフラに最近ではよく使われている。最近ではEnterprise JavaBeansのコンテナを実装する技術として，CORBAが使われることが多い。
CORBAに基づくシステムは，インタフェース部分でオブジェクトにしてあれば実装は何でも構わない。最初に規約が制定されたときは，C言語から利用する方法しか定められていなかったくらいだ。これを利用して既存のシステムをオブジェクト指向的に連携させるために，「Wrapper」オブジェクトを作るアプローチが多い（図7[拡大表示]）。既存のシステム自体はオブジェクトでも何でもなく，いわゆるレガシー・システムであっても構わない。これをつなぐインタフェース部分をCORBA準拠で記述し，全体をコンポーネント化するアプローチである。こうすると非常に大きな粒度のオブジェクトが定義できることになる。
|
|
「そういう考え方もあるんですね」
「何が何でもオブジェクトにしなきゃいけないわけじゃないんだ。ただこれは，意識してやっておかないとズルズルになりかねないので，心がけとしてはできるだけオブジェクトにしましょう，ってところかな」
「うまく分けられればいいんですしね。でもそーいえば，サーバーとクライアントって，どうやって通信してるんでしょう」
「まあ，いろいろだな」
「えー。それじゃわかんないですよお」
