Pourquoi les méthodes d'accesseur de la spécification JavaBean sont-elles devenues la norme pour le développement Java?

La spécification JavaBeans décrit un JavaBean comme

Un Java Bean est un composant logiciel réutilisable qui peut être manipulé visuellement dans un outil de création

Étant donné que la majorité des lignes de code écrites semblent n'avoir rien à voir avec une manipulation visuelle dans un outil de création, pourquoi la spécification JavaBean a-t-elle été la «façon» d'écrire du code orienté objet?

Je voudrais renoncer au getter / setter traditionnel en faveur des interfaces fluides tout au long du code, pas seulement dans les constructeurs, mais crains de le faire car ce n'est traditionnellement pas la façon dont le code orienté objet est écrit en Java.

Les accesseurs de style JavaBean se sont révélés être une bonne correspondance pour toutes sortes de scénarios qui sont similaires au scénario "outil de générateur" d'origine en un point central: les composants sont transmis et manipulés par des conteneurs et des outils génériques ainsi que par le code d'application. Dans un serveur d'applications, vous avez des composants de service auxquels un conteneur EJB ou Spring ajoute des transactions et des injections de dépendance, des modèles de domaine persistants auxquels un ORM ajoute un chargement paresseux et une détection des modifications, et qui peuvent être sérialisés en XML par une bibliothèque sans code spécifique.

Les accesseurs fournissent une API commune qui est très flexible dans la façon dont le composant peut être utilisé - il ne proscrit pas un ordre d'opérations. Chaque appel d'accesseur est indépendant des autres et ils suivent tous le même modèle, vous pouvez donc facilement ajouter des couches génériques qui ajoutent des fonctionnalités sans perturber le modèle d'utilisation prévu.

En revanche, les interfaces fluides sont souvent conçues pour une utilisation ponctuelle: l'objet est créé, une chaîne de méthodes est appelée qui se termine par une méthode qui produit un résultat final, et l'objet est ensuite abandonné. Il y a beaucoup moins de flexibilité (principalement dans les méthodes facultatives) et de généricité, mais c'est exactement l'avantage: l'interface vous force dans un modèle d'utilisation prévu, ce qui la rend très facile à utiliser.

Ainsi, les JavaBeans et les interfaces fluides ont des avantages dans différents scénarios, et ceux que vous devez utiliser dépendent. Et vous pourriez même combiner les deux.

Eh bien, parce que la spécification JavaBeans à laquelle vous liez définit une convention d'accès aux propriétés, les gens ont décidé de tirer parti de la convention et ont construit des cadres autour d'elle. Certains de ces cadres, comme Hibernate, étaient très utiles et sont donc devenus très populaires. Donc, parce que les gens utilisaient des frameworks basés sur la spécification JavaBeans, les javaBeans sont devenus de plus en plus omniprésents, et de plus en plus de frameworks ont été construits autour d'eux.

Les interfaces fluides sont une excellente idée, mais fonctionnent-elles bien avec Spring ou Struts 2? Me bat.