「これでよし，っと。いいコンポーネントがあると助かるわぁ」
「お，調子よさそうじゃん」
「先輩が作ったコンポーネントのおかげですぅ」
「はいはい。いくらほめても何も出ないぞ」
「でも，どうしてコンポーネントだと，こんなに簡単に使えるんですか」
「うーん。やっぱり，独立しているってところがキモなのかな」

　オブジェクト指向プログラミングが登場してから，すぐに提唱されたのが「ソフトウェアIC」などのソフトウェア部品化/再利用のアイデアである。だがそれが現実のものとなるには，長い時間がかかった。

　ソフトウェア部品，すなわちコンポーネントが現実になったのは，米Microsoft社が複合文書の実現機構「OLE（Object Linking and Embedding）」を拡張して，アプリケーション間連携機構に発展させてからだ。そしてその最大の推進役が，Visual Basicである（写真[拡大表示]）。

写真●Visual Basicの統合開発環境とツールパレット
GUI部品を中心に，さまざまなコンポーネントを組み合わせてシステムを開発する。Visual Basicがその方法論を定着させた。

　Visual Basicが導入したコンポーネント規約は2種類ある。4.0版で導入した「VBX」と，OLEベースにした「OCX（OLE Control）」である注1） 。VBXはVisual Basicが普及したことからそれなりに使われたが，Visual Basic以外で使えないという決定的な問題があった。そこで5.0版でOCXを導入した。OCXはOLEから複合文書のための機能などを取り除き，コンポーネントで発生したイベントをコンポーネントを利用するプログラムに通知するインタフェースを設けたものである（詳細は後述）。

　このほか，Javaのコンポーネント規約「JavaBeans」と「Enterprise JavaBeans」，Linuxなどのデスクトップ環境KDE（K Desktop Environment）における「DICOP」など，さまざまある。

オブジェクトであることが第1歩

　コンポーネントを独立した部品として使えるのは，オブジェクト指向の考え方による部分が大きい。オブジェクトであることによって，単に呼び出して処理をするだけでなく状態を保持できるからだ。このことがGUI（グラフィカル・ユーザー・インタフェース）を作る上で非常に有効である。状態の維持をプログラム側で管理しなくて済む。これが一つの独立性である。オブジェクト指向以前の手続き型のライブラリの場合，呼び出したきりになってしまうので，状態に関してはプログラム側で保持しなければならない。そのぶん，ライブラリとのやり取りも発生してしまう。

図1●コンポーネントによるソフトウェア開発
コンポーネントは，ある規約に基づいて実現されている。メソッド名やプロパティ名，引数などを統一しておけば，取り替えが可能だ。

　そしてその独立したコンポーネントは，入れ替えが可能である（図1[拡大表示]）。同じ機能を備え，しかも同じインタフェースのコンポーネントであれば，プログラム本体をほとんど改変することなく入れ替えることができる。例えばWebブラウザのコンポーネントとしてInternet Explorerを使っているプログラムがあるとする。このとき，IEのバージョンが5であるか6であるかは，ごく基本的なAPIのレベルではあまり違いがない。だからOSに組み込まれたIEのバージョンによらず，利用可能なのである注2）。複数企業間でインタフェースを統一すれば，その利用範囲はさらに拡大するだろう。

オブジェクトの実装を関知しない

　もう一つ独立性として挙げられるのは，その動作をするオブジェクトの実装をなんら考慮しなくていいということである（図2[拡大表示]）。コンポーネントを利用するインタフェースを遵守しさえすれば，実際にどのように実現しているのかを関知しなくていい。クラスやオブジェクトの単位で再利用しようとすると，クラスの階層構造や参照関係が複雑に絡み合って適切に取り出せないことがある。コンポーネントであればその心配がない。

図2●コンポーネントの特性
コンポーネントは独立した存在である。そこで必要とされる多種多様なクラスに関しては，コンポーネントを利用するプログラム側で把握しておく必要がない。特定の機能の単位で再利用が可能になる。

　ただこの結果として構造が冗長になる可能性はある。例えば同じGUI部品であっても，Borland Software社が作ったものとMicrosoft社が提供するものを混在させても問題なく利用できる。しかしそれぞれのGUI部品は似たようなものであり，どちらも同じ処理をしている可能性が高い。しかし，独立しているがゆえに，それぞれのコンポーネントで個別にその処理を実装しなければならない注3）。

プログラムにとっては1個のクラス

　利用者から見たコンポーネントは，基本的に1個のクラスである。そこからそのオブジェクトをプログラム中で生成することになる。プログラマが独自に定義したクラスのオブジェクトと，利用するうえでは何ら変わりがない。ただ統合開発環境で利用する場合には，一度コンポーネントをインストールしなければならないことが多い。インストールすれば，ごく普通のクラスとして使える。

　このようにコンポーネントの場合，オブジェクトの大きさ（粒度などとも呼ぶ）がプログラミングにおけるクラスよりも大きいのが一般的である。粒度が大きいことにも意味がある。クラス単位のオブジェクトの粒度では，システム設計の段階では考慮しがたい。しかしコンポーネントのように粒度が大きいと，その単位を想定してシステム設計に反映させやすくなるからだ注4） 。ただ，すべてのコンポーネントが必ず設計段階で考慮されるわけではない。例えばGUI部品などは設計段階ではあまり考慮しない。

（北郷　達郎、八木　玲子）