Discussion :

[grunt2000]

J'ai mon SessionBean,
mon EntityBean,
et bien-sûr mon JavaBean.
Struts me fait utiliser un formulaire qu'il dit être un Bean.
Spring me déclare d'emblée devoir utiliser un FactoryBean.

Les beans sont partout et ne veulent plus rien dire.
Bean est devenu à mes yeux un suffixe parasite. Il n'est pas un jour où je demande l'assistance d'un ami sur un objet inconnu de moi, et qu'il pense m'aider en me déclarant: "C'est un Bean!"

Il y a mille et une natures d'objets en Java.
Il y a les objets métiers, les objets persistants. Les services, les processus, les ordonnanceurs, les contrôleurs, les modèles, les formulaires, les sérialisateurs, les...

mais les Beans, non. Je ne suis pas d'accord.

Qu'il faille un suffixe pour qualifier la nature ou le rôle des objets que l'on manipule, oui.
Mais "Bean", justement, n'apporte plus aujourd'hui aucune précision. Peut-être dans l'esprit de leurs écrivains évoquent-ils l'idée d'une classe pourvue d'un constructeur public sans arguments et de getters et setters publics? Ce n'est même plus sûr...

Je crois que le Bean est une notion qui a aujourd'hui perdu tout son sens à force d'emploi abusif, de mise à toutes les sauces. Et qu'il faut éviter de l'employer si l'on veut conserver des nommages d'objets clairs.

[eclesia]

c'est pas faux
ps : tu oublis NetBeans

sérieusement : il y a du vrai, pour moi un bean est une classe autonome, qui en gros "peu marcher seule", mais ce n'est sans doute pas la définition d'origine.

[kedare]

ps : tu oublis NetBeans

et Mr Beans

[gifffftane]

Oui, mais le système des get et set est utilisé partout ; il est difficile de l'ignorer, et même contre-productif je trouve.

Le découpage des méthodes en accesseurs, en événements etc est bon, il me semble.

Perso j'essaie de résoudre le problème en me donnant des règles assez précises de travail avec les... beans (donc avec tous les objets).

Pour les abus de langage, ils sont malheureusement inhérant à notre métier... la partie chapelle, ou marketing, ou évangéliste des choses ; elle ne veut rien dire, n'a pas de rapport avec le concret, probablement même est-elle là pour le cacher, mais il est difficile de s'en passer pour le monde des affaires.

[OButterlin]

C'est vrai que "bean" ne veut plus dire grand chose, ceci dit, à l'origine du moins, ça supposait quand même le respect de certaines choses (que je t'invite à consulter sur http://fr.wikipedia.org/wiki/JavaBeans)

Il n'y a pas plus d'intérêt à suffixer un objet par Bean que par n'importe quoi d'autre, mais bon, ça doit faire "in"

A+

[grunt2000]

Il n'y a pas plus d'intérêt à suffixer un objet par Bean que par n'importe quoi d'autre, mais bon, ça doit faire "in"[...]

Sur ce point, je ne suis particulièrement pas d'accord.

J'ai un objet Intervention sous les yeux. Ou même, si vous voulez, un objet InterventionBean:

- Est-ce un objet métier? Il aurait des variables membres description, date, durée, coût... et des méthodes membres adaptées.

- Est-ce un service? Il serait porteur d'entrées de service répondant aux cas d'utilisation: déclarerIntervention(...), facturerIntervention(...), planifierIntervention(...), etc.

- Est-ce un formulaire de saisie? Il aurait des contrôles graphiques dessus ou l'image de leur contenu.


Si le nom de l'objet peut être complété d'un préfixe ou suffixe précisant sa nature, il aide notablement le lecteur du code (qui peut, par ailleurs, toujours se référer aux commentaires ou javadoc accompagnant l'objet. Mais pourquoi l'entrainer dans ces méandres, si le nom peut déjà le guider?).

Intervention pour un objet métier. Personnellement, je ne leur mets pas de préfixe ni de suffixe. Ils se représentent eux-mêmes par leur seul nom.

InterventionService pour un service.

InterventionForm pour un formulaire.

etc.