Java Beans とは？

Java Beansの定める Beanの定義は、最初のうちは「つかみどころがない」ような 印象を受けるかもしれません。ここでは Beanとはいったいどんなものなのかを、 その一番基本的な部分から解説しましょう。
Beanを構成するもの

Java Beansは Javaで開発される再利用可能な部品の標準的な規格を 提供するものです。 その規格を満たす個々の部品は Bean と呼ばれます。 今まで学んできた Javaのクラスと Beanとはどこがちがうのでしょうか？　 まず次の事実はとても重要です。

一口に Beanと言いましたが、実は Beanは非常に幅広い対象です。 単純な Buttonのような Beanもあれば、 表計算やワープロソフトのような大規模な Beanも作成可能です。 そうした複雑な Beanの場合は、 本体のクラスの他に、部品となるいくつかのクラス、 イメージのデータファイルなども Beanを構成する要素となります。 また、Beanに関する情報を取り扱うためのクラス(BeanInfo)や Beanの設計を画面上で行うための専用のクラス(Customiser, PropetyEditor)も Beanの一部として含んでいる場合もあります。 また部品となるクラスが別の Beanであることも珍しくありません。


Beanはさまざまな構成要素からなる

おそらくこれまで学んできたものの中で Beanに最も似た存在はアプレットでしょう。 アプレットもさまざまな規模のプログラムとして存在することが可能でした。 アプレットはそれ自身が半ば独立した存在であると同時に、 HTMLのページの中に埋め込まれるという部品としての性格も持っていました。 この点も Beanの考え方と共通しています。 実際、ほとんどのアプレットはほとんどそのまま Bean化することが可能です。 ただし、 アプレットが HTMLのページの上という限定された場所でしか利用されないのに対し、 Beanはもっと幅広い用途に利用されるものとして設計されます。 また Beanの場合、GUIベースの開発ツールで開発されるということを常に意識して 設計される点も、従来にはなかった考え方です。
従来のクラスの場合にはアプレットも含め、 ソースコードもしくはバイトコードとクラスがはっきりとした対応を持っています。 これに対して Bean は開発環境との関連やデータのファイルなどの存在も含めた 複合的な存在です。 Beanの中核となるのは確かに Javaのある１つのクラスなのですが、 そのクラスのバイトコードのファイルだけでは Beanとは見なされないのです。 したがって Beanという名前のクラスやインターフェイスは存在しません。 アプレットを開発する際の Appletクラスの継承のようなことは行われません。 これが最初のうち理解しにくい原因かもしれません。 さらに Beanは GUIベースの開発ツールを通じて取り扱われます。 JDKの伝統的なコマンドラインとテキストエディタを中心にした取り扱いとは 全く異なったスタイルにも戸惑いを感じるかもしれません。

Beanとなるための条件

Java Beansは Java言語のクラスが満たすべき条件以外に、 新たにいくつかのルールを導入しています。 Javaの文法上は正しいコードを記述したとしても、 そのままでは Beanにはなれません。 まず、最も根本的な条件は次のことです。

そもそも Java Beansが誕生した背景には、 GUIベースの開発ツールの存在がありました。 開発ツールが作り出すクラスの互換性や再利用性を保証するために何らかの 基準が必要になったのです。 つまり、上の条件は本来の目標を単に抽象的に述べただけにすぎません。 実際にはさらに細かい条件を要求することになります。 （注意：上の要求は「Beanを開発する時に Beanが目に見えること」 ということです。「Beanが実行される時に Beanが目に見えること」 と混同してはいけません。つまりウィンドウを持たない存在であっても Beanになれるということです。）
Java Beansの要求するルールのうちのいくつかはごく自然な要求です （たとえば publicなコンストラクタを持つということ）。 しかし、いくつかのルールは Java Beansが新しい規格として定めたもので、 従来の Javaのクラスでは必ずしも常に必要となるとは限らないものです。 また、Java Beansの方針を支えるために JDK1.1 から Javaの言語仕様や クラスライブラリに多くの追加が行われ、それらとの密接な関連も理解する 必要があります。
それぞれのルールの意味は後で改めて説明するとして、 まずルールをひととおり眺めてみましょう。 Beanの中核となる Javaのクラスは下記の条件を備えている必要があります。
  1. publicでかつ引数なしのコンストラクタを持つこと。
  2. java.io.Serializableインターフェイスを継承していること。 （直接実装しても、実装したクラスのサブクラスであっても、どちらでも可）
  3. メソッドの名前は Java Beansに定められた命名規則に従うこと。
1) Beanは抽象クラスであったり、パッケージ内だけでしか参照できない クラスであってはなりません。 これは他のアプリケーションでそのまま再利用できるためには当然のことです。 引数なしのコンストラクタが必要なのは、 開発ツールが任意の Beanのオブジェクトを動的に作り出すことができるように するためです。
2)JDK1.1 から新たに導入された機能に Serialization の機構があります （ 詳しくは第８週の解説を参照 ）。 これはオブジェクトの情報をそのままファイルやネットワークのソケットなどの ストリームに入出力する機構です。 Java Beansの開発ツールはこの Serialization を用いてオブジェクトの 情報を保存したり復活させたりします。 したがって Beansは必ず Serializationの対象となるよう Serializableを継承します。
3)Beanのメソッドのうち、内部の状態を取り出したり設定したりするメソッドは、 必ず getXXX(), setXXX() のような名前にする必要があります。 開発ツールがそれらの名前を手がかりにしてメソッドの性質を識別するからです。

Beanであることの識別

クラスだけでは Beanとは見なされないと先に述べましたが、 では Beanであることの情報はどこに存在し、 どのようにして識別されるのでしょうか？　 Beanはファイルの集合体でしたから、 そうした集合体そのものに Beanであるという情報を記述することになります。 Beanは必ず Jar形式のファイルによって配布されます （ Jarについては第12週の解説を参照 ）。 Jarファイルはその内部にマニュフェスト・ファイルというファイルの情報を 記憶するための部分を持ちます。その中に「Beanであるということ」を 記述しておきます。具体的には次のように Beanであることを示す情報を Jarファイル生成時につけ加えます。 


Manifest-Version: 1.0

Java-Bean: True

Java Beansは「デザインパターン」か？

オブジェクト指向プログラミングで大規模なアプリケーションを開発する経験が 蓄積されてくると、 より効率よく開発するためのさまざまな工夫が提案されるようになりました。 それらを体系化しクラスを設計するための指針としたものが 「デザインパターン(Design Pattern)」と呼ばれるものです。 たとえば Java Beansが要請するメソッドの命名規則などは、 広い意味でデザインパターンの手法の１つと言うことができます。
ただし最近はデザインパターンという言葉の力点は、 「クラスの設計のパターンの分類」と「お手本の提供」にあるようです。 ちょうど手続き指向プログラミングで経験が積み重ねられていくに従って、 より洗練されたアルゴリズムが蓄積されていったのと事情が似ています。 Java Beansはそうしたものの提供を目指したものではありません。 その意味では「Java Beansはデザインパターンだ」 と言うと誤解を招くことになるかもしれません。