Discussion :

[Glob]

Bonjour,

je me pose des questions quant à la pertinence d'écrire des accesseurs pour des JavaBeans dans un contexte SOA.

Quelqu'un peut-il argumenter en faveur de l'utilité de getters et setters qui ne font rien de particulier (mis à part accéder à une propriété)?

Pourquoi ne pas simplement avoir des propriétés publiques?

Merci

A+

[adiGuba]

Salut,


Comme toujours, on y gagne les avantages des accesseurs/mutateurs :

• On peut contrôler plus finement l'accès aux propriétés via la visibilité.
• On peut utiliser un type différent en interne.
• On peut rajouter des contrôles sur les valeurs des attributs.
• On peut rajouter des listeners sur les modifications.
• Il est possible de les redéfinir dans une classe fille.

a++

[Glob]

Hello.

Merci pour cette réponse rapide. J'ai oublié de préciser que mes JavaBeans servent uniquement de containers à données dans un contexte SOA:

- je me moque complètement du véritable type de données;
- ce sont les services qui gèrent que les données soient cohérentes au moment où on les utilise;
- ce sont les services qui préviennent d'autres autres listeners
- je me méfie de l'héritage comme de la guigne et n'y ai recours qu'en cas de nécessité absolue ou gain évident.

Dans ce genre de contexte, j'imagine que livrer mes propriétés en pâture publique n'est pas réellement choquant.

D'autres arguments pour les get/set?

Merci et A+

[Onice]

Un simple transient sur un getter te permet de ne pas exposer la propriété dans ton service.

Ca peut toujours servir afin d'éviter de faire transiter de grosses grappes d'objets ou de propriétés techniques dans ton infrastructure SOA.

[Glob]

Un simple transient sur un getter

Hello.

Mon Eclipse me refuse "transient" sur un getter. Peux-tu me préciser la syntaxe et l'avantage par rapport à une propriété transient?

Merci

A+

[Onice]

Je parlais de l'annotation @Transient, qui signifie que la propriété n'est pas propagée lors de la sérialisation de l'objet.