Principes et conseils : Conception des Java beans
Rubriques
Introduction
Ces principes et conseils traitent de la conception des Java beans et des différents choix qui s'offrent au concepteur.
Pour plus d'informations sur les Java beans, voir Concepts :
Bean Java.
Propriétés des Java beans
A l'intérieur d'une classe, une valeur de propriété peut être stockée comme un champ private ou être calculée. Le concepteur peut choisir de précalculer la valeur de la propriété ou d'utiliser une évaluation paresseuse, dans laquelle la valeur ne sera calculée que lorsqu'elle sera appelée.
Le concepteur peut également borner ou contraindre la propriété. Si la propriété est bornée ou contrainte, le concepteur peut décider d'un mécanisme d'événements et de notification.
Evénements et notification
Pour l'implémentation du mécanisme de notification, le concepteur peut choisir entre deux options :
- Utiliser les classes PropertyChangeSupport et PropertyChangeEvent du package java.beans.
- Créer un mécanisme de notification personnalisé.
Les classes du package java.beans fournissent une implémentation applicable
dans la plupart des situations. PropertyChangeEvent contient la référence à l'objet qui a déclenché l'événement, le nom de la propriété sous forme d'objet String, et deux objets représentant l'ancienne et la nouvelle valeur de la propriété. La classe PropertyChangeSupport
conserve une collection de PropertyChangeListeners et contient le code
implémentant la notification dans la méthode firePropertyChange.

PropertyChangeSupport est couramment utilisé dans les Java beans qui constituent les interfaces utilisateur.
La notification personnalisée peut convenir lorsque le temps système de création d'objets événements doit être réduit. Elle présente néanmoins l'inconvénient de nécessiter l'implémentation du mécanisme de notification par l'implémenteur. L'implémenteur de la notification personnalisée doit garder à l'esprit le fait qu'une unité d'exécution différente peut ajouter ou retirer des programmes d'écoute pendant le processus de notification. Pour fournir le comportement correct, la plupart des solutions créent une copie de la collection qui contient les programmes d'écoute. La notification est alors effectuée à l'aide de la copie. La plupart des implémentations publiées créent cette copie au début du processus de notification, ce qui entraîne la création de nombreux clones et la dégradation des performances. Néanmoins, les notifications étant plus fréquentes ques les additions ou retraits de programmes d'écoute, une copie à durée de vie plus longue peut être créée à l'avance pendant l'ajout ou le retrait des programmes d'écoute, puis réutilisée pour les notifications, ce qui accélère l'exécution.
Si l'on considère la productivité des développeurs, la notification personnalisée ne doit être envisagée que lorsqu'il est avéré que les performances de la prise en charge des modifications de propriétés par le package java.beans
constituent le goulet d'étranglement.
Les exemples qui suivent démontrent à la fois l'utilisation de la prise en charge des modifications de propriétés par le package java.beans et l'utilisation d'un mécanisme de notification personnalisé.
Exemple : Bean Java Tank utilisant java.beans.PropertyChangeSupport
Nous avons ici un Java bean représentant un réservoir (Tank), doté d'une propriété bornée :
level (niveau). Lorsque le niveau du réservoir Tank est modifié, Tank
déclenche un événement PropertyChangeEvent qui est traité par l'objet TankController.

Exemple : Bean Java Tank utilisant une notification personnalisée
Dans l'exemple qui suit, la classe Tank est implémentée par un mécanisme de notification personnalisé plus efficace, qui évite la création d'objets pendant la notification.

|