Java Property Change auditeurs

Question

Je voudrais savoir comment la propriété java beans change d'écouteurs. Utilisent-ils, EventListeners à l'intérieur? Est-il bon à utiliser, les écouteurs de changement de propriété lorsque nous pouvons faire la même chose avec l'implémentation POJO du modèle de médiateur. Je veux dire la performance sage?

Merci J

Answer 1

L'avantage est dans le domaine du couplage. mediator requiert que vos classes soient conscientes du médiateur (par exemple en passant l'instance de médiateur dans le constructeur). Les médiateurs peuvent être très puissants et peuvent certainement fournir une notification plus efficace, mais au prix d'une complexité considérable.

Par contraste, le modèle de conception Observer (dont les écouteurs de modification de propriété JavaBeans sont une implémentation) est beaucoup plus facile à implémenter. Mais ils peuvent avoir un comportement émergent intéressant dans les systèmes complexes.

Dans de nombreuses situations, Observer est plus que suffisant (en particulier dans les zones où JavaBeans a tendance à être utilisé). Dans d'autres situations, il est loin d'être adéquat - un bon exemple est la propagation d'événements dans le Glazed Lists library. Ils ont fini par devoir utiliser un EventPublisher (qui est un médiateur) pour optimiser l'ordre de notification des événements, et s'assurer que les dépendances sont respectées avant la propagation des événements. Donc, la réponse à votre question est que ce n'est pas une question de POJOs par rapport à JavaBeans. C'est une question de modèle de conception (observateur ou médiateur) qui a le plus de sens pour un cas d'utilisation donné. Les deux modèles se concentrent sur le découplage des parties du système les unes des autres. Et les deux modèles ont des situations où ils sont appropriés. Pour un grand nombre de situations, Observer est très bien - et est vraiment, vraiment facile à écrire.

Je devrais également mentionner que l'utilisation d'objets d'événement intermédiaires est commune dans les implémentations Observer et Mediator, c'est donc un problème secondaire. Mais les machines virtuelles modernes sont vraiment efficaces pour traiter des objets de courte durée comme celui-là - donc ce n'est vraiment pas un problème.

Answer 2

Le code que vous recherchez est java.beans.PropertyChangeSupport. Vous l'utilisez comme ceci:

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)); 

} 

Le principal avantage de cette API est qu'elle est connue de tous. Le principal inconvénient est que l'API Beans est assez ancienne, encombrante du point de vue d'aujourd'hui et très limitative.

Par exemple, vous avez besoin du nom d'une propriété dans plusieurs endroits. Cela signifie soit que vous devez copier une chaîne (qui casse si vous renommez la propriété), soit vous devez définir manuellement une constante String pour chaque champ qui est fastidieux.

La mise en œuvre elle-même est assez rapide et suit le modèle de conception Observer. Bien sûr, il existe d'autres façons de mettre en œuvre cela. Le prix serait que ce n'est plus un bean car il ne suit pas l'API. Par conséquent, vous ne pouvez pas utiliser votre objet dans de nombreux frameworks sans code de collage supplémentaire.