Pour moi c’est des notions différentes, en particulier :
les beans doivent être modifiables (les objets fonctionnels ne le sont qu’au besoin),
les beans doivent être sérialisables (ça n’est pas un besoin pour les objets utilisés dans le contexte fonctionnel),
les beans doivent pouvoir être étendus (ça n’est pas un besoin pour les objets utilisés dans le contexte fonctionnel)
les beans sont censés gérer des listeners, ce qui sort du cadre de l’objet « sans comportement »
les POJO c’est juste un acronyme pour parler des objets qui ne dépendent pas d’un framework particulier (en particulier face aux EJB à l’époque)
On peut se servir de « beans » dans les parties fonctionnelles de code Java, mais ça n’est pas nécessaire que les objets utilisés recouvrent toutes les parties des beans. En fait, ça fait longtemps que je n’entends plus grand-monde parler de « beans » ou « JavaBeans » hors du contexte de code historique. Éventuellement pour parler d’un objet qui sert uniquement de « structure de données » (c’est ce dont il s’agit ici), mais j’entends plutôt parler de POJO, « data object » (par mimétisme avec les data class de Kotlin) ou de Record dans ce cas précis.
[^] # Re: intéressant !
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Un point sur la programmation objet (POO) – La POO, ses problèmes, et qu’en faire . Évalué à 3.
Pour moi c’est des notions différentes, en particulier :
On peut se servir de « beans » dans les parties fonctionnelles de code Java, mais ça n’est pas nécessaire que les objets utilisés recouvrent toutes les parties des beans. En fait, ça fait longtemps que je n’entends plus grand-monde parler de « beans » ou « JavaBeans » hors du contexte de code historique. Éventuellement pour parler d’un objet qui sert uniquement de « structure de données » (c’est ce dont il s’agit ici), mais j’entends plutôt parler de POJO, « data object » (par mimétisme avec les
data classde Kotlin) ou de Record dans ce cas précis.La connaissance libre : https://zestedesavoir.com