クラスっぽいJavaのコンポーネントとパイプっぽいDelphiのDBアクセス

最近Delphiのコンポーネント開発に関する記事を翻訳していて、JavaとDelphiのコンポーネントの違いを改めて感じています。EJBがはやり始めた頃、Javaの世界では、コンポーネントの流通を活性化するとかいろいろ試みがあったけれども、どうも当初の意図したところには到達していないように思っていたのですが、そういえば当時も、「そもそも、コンポーネントの部品としての立ち位置に違いがあるんじゃないの？」と感じていたのでした。

コンポーネントを簡単に言うと「プログラム部品」なのですが、大抵の場合、その実体はクラスの一種です。では、クラスとコンポーネントの違いは？と言われると、なんとなく「コンポーネントのほうがより抽象化されている」とか「部品として独立性が高い」とか、分かったような分からないような回答になってしまいます。

Delphiに代表されるようなビジュアルRADツールは、フォームと呼ばれる画面にボタンなどの部品をマウス操作でペタペタ貼り付けて、ボタンに表示される文字や押されたときの動作を定義してプログラムを開発します。このときのボタンなどの部品を指して、コンポーネントと言うと、「なるほど」とイメージできるかと思います。

とはいえ、コンポーネントには、画面に表示される部品（これは、別にコントロールという呼び名があります）だけでなく、データアクセスだったりロジックだったり、いろいろな部品があります。Delphiのようなツールの分かりやすさは、こういった部品もペタっと画面に貼って、同じように設定できる点です。部品はあくまでもビジュアル操作の殻に守られて、ユーザーには、本当に部品として認識されます。そして、画面を中心とした設計を可能にしているといえます。

一方、Javaでコンポーネントといった場合、SwingのようなUIコントロールとしての JavaBeans、サーブレットなどで使用するロジックやデータを実装するJavaBeans、それとEJBなどがあります。Javaのコンポーネントでは、Delphiのようにペタペタ貼り付けるような使い方は、ごく一部だということが分かります。部品としては独立していますが、あくまでもコードの中で部品を利用するという使い方になります。言い換えれば、Javaの部品は、ビジュアル操作の殻の隙間から、クラスが見え隠れしています。このことは、言語構造的に透明性があって、分かる人にはかえって居心地がよく感じるのですが、部品を使うだけに徹したい人にとっては、ちょっと複雑に見えます。

でも、もっと重要な違いは、データの供給方法にあるんじゃないかと思っています。

Delphiでは、データベースアクセスコンポーネントというのがあって、データをUIに供給します。このコンポーネントは、データそのものというより、データベースとUIの間をつなぐパイプのようなものです。注文データにアクセスしたいなら、データアクセスコンポーネントを配置してORDERテーブルにアクセスします。つまり、このコンポーネントはパイプです。

Javaの場合、大抵Orderオブジェクトなんかを定義して、これにアクセスします。Orderオブジェクトの永続化はどうするかな、とJ2EEやらオープンソースやら、いろいろな仕掛けを使います。データの供給は、これとは別のクラスが担当します。コンポーネントといいながら、あっちこっちでそれを使うためにクラスが出てきます。

ちょっとポンチ絵にしてみました。かなりデフォルメしてますのでご容赦を。

画面中心で考えた場合、Delphiのようなやり方が単純で簡単です。しかし、Webをはじめとする多層型のシステムになった場合、データベースから直接パイプでデータを流し込むやり方は具合が悪いことが多くなります。クライアントのキャッシュ、並行処理などなど、いろいろ問題が出てきます。むしろJavaのようなやり方の方が、こうしたサーバ側の面倒な処理をブラックボックス化して賢くこなします。画面中心ならDelphi、サーバ側を中心に考えるならJava。こういう結論になるのですが、両方うまくこなしてくれる処理系はまだないように見えます。.NETもどちらかというとDelphi寄り。

Java風のやり方だと、扱うデータによってずいぶん実装も変わってしまうように見えるんだけど、Javaのコンポーネント流通って、そもそもどのあたりのコンポーネントを指していたんだろうと、今さらのように考えてしまう今日この頃です。