ガイドライン JavaBeans の設計
トピック
概論
このガイドラインは、JavaBeans の設計と設計者の選択肢を中心に説明します。
JavaBeans について詳しくは、『概念: JavaBeans』を参照してください。
JavaBeans のプロパティー
内部的に、プロパティー値は、private フィールドとして保存できますが、計算も可能です。
設計者の選択肢として、プロパティー値をあらかじめ計算しておくことも、または呼び出し側から照会された時にのみ値を計算する遅延評価を使用することもできます。
設計者には、プロパティーの結合や制約という選択肢もあります。プロパティーに結合または制約を適用する場合、設計者はイベントと通知のメカニズムを決定しなければなりません。
イベントと通知
通知メカニズムの実装について、設計者には、次の 2 つの選択肢があります。
- java.beans パッケージから PropertyChangeSupport クラスと PropertyChangeEvent クラスを使用します。
- カスタム通知メカニズムを作成します。
java.beans パッケージのクラスは、多くの状況に適用できる実装を提供します。PropertyChangeEvent には、イベントを起動するオブジェクトへの参照、String としてのプロパティー名、プロパティーの古い値と新しい値を表わす 2 つのオブジェクトが含まれます。クラス PropertyChangeSupport
は、PropertyChangeListeners のコレクションを保持し、メソッド firePropertyChange内の通知用のコードを含みます。

PropertyChangeSupport は、通常、ユーザー・インターフェースの一部を構成する JavaBeans に使用されます。
カスタム通知は、イベント・オブジェクトの作成のオーバーヘッドを最小限にする必要がある場合に適しています。欠点は、実装担当者が通知メカニズムを実装する必要があることです。カスタム通知の実装担当者は、通知プロセスの間に別のスレッドがリスナーを追加または削除する可能性があることに注意する必要があります。正しい振る舞いが行われるために、多くの場合、リスナーを保持するコレクションのコピーを作成し、コピーを使用して通知を実行します。最もよく使用されている実装では、通知プロセスの開始時にコピーを作成し、その結果、多くのクローンが作成されてパフォーマンスの低下を招きます。しかし、通知は、リスナーの追加や削除よりも頻度が高いため、リスナーの追加または削除時にあらかじめ長期存続コピーを作成し、通知に再利用すると、実行を高速化することができます。
開発者の生産性を考慮すると、カスタム通知は、java.beans パッケージからのプロパティー変更のサポートのパフォーマンスがボトルネックであるとわかっている場合にのみ試すべきです。
以下の例では、java.beans パッケージからのプロパティー変更サポートと、カスタム通知メカニズムの両方を使用しています。
例: java.beans.PropertyChangeSupport を使用する Tank JavaBean
これは、Tank という JavaBean で、これにはバウンド・プロパティー level があります。Tank のレベルが変更されると、Tank は PropertyChangeEvent を発行します。このイベントは、TankController オブジェクトによって処理されます。

例: カスタム通知を使用する Tank Java Bean
以下の例で、クラス Tank には、より効率的なカスタム通知メカニズムが実装されています。このメカニズムでは、通知中にオブジェクトを作成しません。

|