Dlaczego metody akcesorów ze specyfikacji JavaBean stały się standardem programowania Java?

JavaBeans Specyfikacja opisuje JavaBean jako

Java Bean to komponent oprogramowania wielokrotnego użytku, którym można manipulować wizualnie w narzędziu do budowania

Skoro większość napisanych wierszy kodu wydaje się nie mieć nic wspólnego z manipulowaniem wizualnym w narzędziu do budowania, dlaczego specyfikacja JavaBean była „sposobem” pisania kodu obiektowego?

Chciałbym porzucić tradycyjny getter / setter na rzecz płynnych interfejsów w całym kodzie, nie tylko w programach budowniczych, ale boją się tego, ponieważ tradycyjnie nie jest to sposób, w jaki kod zorientowany obiektowo jest pisany w Javie.

Akcesoria w stylu JavaBean okazały się dobrze pasować do wszystkich rodzajów scenariuszy, które są podobne do oryginalnego scenariusza „narzędzia do budowania” w jednym głównym punkcie: komponenty są przekazywane i manipulowane przez ogólne kontenery i narzędzia, a także kod aplikacji. Na serwerze aplikacji masz komponenty usługi, do których kontener EJB lub Spring dodaje transakcje i zastrzyki zależności, trwałe modele domen, do których ORM dodaje leniwe ładowanie i wykrywanie zmian, i które mogą być serializowane do XML przez bibliotekę bez żadnego specjalnego kodu.

Akcesoria zapewniają wspólny interfejs API, który jest bardzo elastyczny w sposobie używania komponentu - nie zakazuje kolejności operacji. Każde wywołanie akcesorium jest niezależne od innych i wszystkie mają ten sam wzór, dzięki czemu można łatwo dodawać ogólne warstwy, które dodają funkcjonalność bez zakłócania zamierzonego wzorca użytkowania.

W przeciwieństwie do tego, płynne interfejsy są często projektowane do jednorazowego użycia: obiekt jest tworzony, wywoływany jest łańcuch metod, który kończy się metodą, która daje końcowy wynik, a następnie obiekt jest porzucany. Jest o wiele mniej elastyczności (głównie w metodach opcjonalnych) i ogólności, ale jest to dokładnie zaleta: interfejs zmusza cię do zamierzonego wzorca użytkowania, dzięki czemu jest bardzo łatwy w użyciu.

Tak więc JavaBeans i płynne interfejsy mają zalety w różnych scenariuszach, a to, które powinieneś użyć, zależy. I możesz nawet połączyć oba.

Ponieważ specyfikacja JavaBeans, do której prowadzi łącze, określa konwencję dostępu do właściwości, ludzie postanowili skorzystać z tej konwencji i zbudować wokół niej ramy. Niektóre z tych frameworków, takie jak Hibernacja, były dość przydatne i dlatego stały się bardzo popularne. Ponieważ ludzie używali frameworków opartych na specyfikacji JavaBeans, javaBeans stał się coraz bardziej wszechobecny i wokół nich budowano coraz więcej frameworków.

Płynne interfejsy to świetny pomysł, ale czy grają dobrze w Spring czy Struts 2? Bije mnie