Warum sind die Accessor-Methoden aus der JavaBean-Spezifikation zum Standard für die Java-Entwicklung geworden?

Die JavaBeans-Spezifikation beschreibt eine JavaBean als

Eine Java Bean ist eine wiederverwendbare Softwarekomponente, die in einem Builder-Tool visuell bearbeitet werden kann

Da die Mehrheit der geschriebenen Codezeilen nichts damit zu tun zu haben scheint, in einem Builder-Tool visuell bearbeitet zu werden, warum war die JavaBean-Spezifikation der "Weg", objektorientierten Code zu schreiben?

Ich möchte auf den traditionellen Getter / Setter zugunsten von Fluent Interfaces im gesamten Code verzichten, nicht nur in Buildern, sondern befürchte dies, da dies normalerweise nicht die Art und Weise ist, wie objektorientierter Code in Java geschrieben wird.

Accessoren im JavaBean-Stil passen in einem Kernpunkt gut zu allen Arten von Szenarien, die dem ursprünglichen Szenario "Builder-Tool" ähnlich sind: Komponenten werden von generischen Containern und Tools sowie Anwendungscode weitergegeben und bearbeitet. In einem App-Server verfügen Sie über Servicekomponenten, zu denen ein EJB- oder Spring-Container Transaktionen und Abhängigkeitsinjektionen hinzufügt, zu persistenten Domänenmodellen, zu denen ein ORM das verzögerte Laden und Erkennen von Änderungen hinzufügt und die von einer Bibliothek ohne bestimmten Code in XML serialisiert werden können.

Accessoren bieten eine gemeinsame API, die sehr flexibel in der Verwendung der Komponente ist - sie verbietet keine Reihenfolge der Vorgänge. Jeder Accessor-Aufruf ist unabhängig von anderen und alle folgen demselben Muster, sodass Sie problemlos generische Ebenen hinzufügen können, die Funktionen hinzufügen, ohne das beabsichtigte Verwendungsmuster zu stören.

Im Gegensatz dazu sind fließende Schnittstellen häufig für die einmalige Verwendung konzipiert: Das Objekt wird erstellt, eine Methodenkette wird aufgerufen, die mit einer Methode endet, die ein Endergebnis liefert, und das Objekt wird dann aufgegeben. Es gibt viel weniger Flexibilität (meistens bei optionalen Methoden) und Generizität, aber genau das ist der Vorteil: Die Benutzeroberfläche zwingt Sie zu einem beabsichtigten Verwendungsmuster, was die Verwendung sehr einfach macht.

JavaBeans und fließende Schnittstellen haben also in verschiedenen Szenarien Vorteile, und welche Sie verwenden sollten, hängt davon ab. Und Sie könnten sogar beides kombinieren.

Nun, da die JavaBeans-Spezifikation, mit der Sie verknüpfen, eine Konvention für den Zugriff auf Eigenschaften definiert, haben sich die Leute entschlossen, die Konvention zu nutzen und Frameworks darauf aufzubauen. Einige dieser Frameworks, wie z. B. Hibernate, waren sehr nützlich und wurden daher sehr beliebt. Da die Benutzer Frameworks verwendeten, die auf der JavaBeans-Spezifikation basierten, wurden JavaBeans immer allgegenwärtiger und es wurden immer mehr Frameworks um sie herum erstellt.

Fließende Schnittstellen sind eine großartige Idee, aber spielen sie gut mit Spring oder Struts 2? Schlägt mich.