Javaプロパティ変更リスナー

Question

私は、Java Beanのプロパティがリスナーの動作を変更する方法を知りたいと思います。 内部でEventListenersを使用していますか？ メディエーターパターンのPOJO実装 と同じことができるときは、プロパティー変更リスナーを使用するとよいでしょうか。パフォーマンスは賢明ですか？

おかげ J

Answer 1

利点はカップリング領域です。 mediatorでは、クラスがメディエータを認識する必要があります（メディエータインスタンスをコンストラクタに渡すなど）。メディエータは非常に強力であり、より効率的な通知を確実に提供できますが、かなりの複雑さを犠牲にします。

対照的に、Observerデザインパターン（JavaBeansプロパティの変更はリスナーが実装されている）は、実装がずっと簡単です。しかし、複雑なシステムでは面白い緊急の行動を起こすことがあります。

Observerは、JavaBeansが使用されることが多い分野では、それ以上のものです。他の状況では、それは十分に近いところではありません。良い例は、Glazed Lists libraryのイベント伝播です。 EventPublisher（メディエータ）を使用してイベント通知の順序を最適化し、イベントが伝播する前に依存関係が満たされていることを確認する必要があります。

あなたの質問に対する答えは、これはPOJO対JavaBeansの問題ではないということです。これは、どのような設計パターン（オブザーバまたはメディエータ）が特定のユースケースに対して最も理にかなっているかどうかという問題です。両方のパターンは、システムの一部を互いに切り離すことに焦点を当てています。どちらのパターンも適切な状況があります。膨大な数の状況では、Observerはうまくいきます。本当に簡単に書くことができます。

また、ObserverとMediatorの両方の実装で中間イベントオブジェクトの使用が一般的であることにも言及する必要があります。しかし、現代のVMは、そのような短命のオブジェクトを扱うのに本当に効率的です。つまり、それは本当に問題ではありません。

Answer 2

あなたが探しコードがjava.beans.PropertyChangeSupportです。

protected transient PropertyChangeSupport changeSupport = new PropertyChangeSupport (this); 

public void addPropertyChangeListener (String propertyName, PropertyChangeListener listener) 
{ 
    changeSupport.addPropertyChangeListener (propertyName, listener); 
} 

public void removePropertyChangeListener (String propertyName, PropertyChangeListener listener) 
{ 
    changeSupport.removePropertyChangeListener (propertyName, listener); 
} 

public void firePropertyChange (String propertyName, BigDecimal oldValue, BigDecimal newValue) 
{ 
    if (oldValue != null && newValue != null && oldValue.compareTo (newValue) == 0) { 
     return; 
    } 
    changeSupport.firePropertyChange(new PropertyChangeEvent(this, propertyName, 
               oldValue, newValue)); 

} 

このAPIを使用する主な利点は、誰もが慣れていることです。主な欠点は、Beans APIがかなり古く、今日の観点から非常に制限されていることです。

たとえば、多くの場所でプロパティの名前が必要です。これは、文字列（プロパティの名前を変更したときに改行する文字列）をコピーする必要があること、または退屈なすべてのフィールドに対して文字列定数を手動で定義する必要があることを意味します。

実装自体はかなり速く、Observerデザインパターンに従います。もちろん、これを実装する他の方法もあります。 APIに従わないため、これはもはやBeanではないということになります。したがって、追加のグルーコードなしで多くのフレームワークでオブジェクトを使用することはできません。