Perché i metodi di accesso dalle specifiche JavaBean sono diventati lo standard per lo sviluppo Java?

La specifica JavaBeans descrive un JavaBean come

Un Java Bean è un componente software riutilizzabile che può essere manipolato visivamente in uno strumento di creazione

Poiché la maggior parte delle righe di codice scritte sembrano non avere nulla a che fare con la manipolazione visiva in uno strumento di creazione, perché la specifica JavaBean è stata il "modo" di scrivere codice orientato agli oggetti?

Vorrei rinunciare al tradizionale getter / setter in favore di Fluent Interfaces in tutto il codice, non solo nei costruttori, ma temo di farlo poiché questo non è tradizionalmente il modo in cui il codice orientato agli oggetti è scritto in Java.

Gli accessori in stile JavaBean hanno dimostrato di essere una buona corrispondenza per tutti i tipi di scenari che sono simili allo scenario "strumento generatore" originale in un punto centrale: i componenti vengono passati e manipolati da contenitori e strumenti generici, nonché dal codice dell'applicazione. In un server di app hai componenti di servizio a cui un contenitore EJB o Spring aggiunge transazioni e iniezioni di dipendenze, modelli di dominio persistenti a cui un ORM aggiunge il caricamento lento e il rilevamento delle modifiche e che possono essere serializzati in XML da una libreria senza alcun codice specifico.

Gli accessori forniscono un'API comune che è molto flessibile nel modo in cui il componente può essere utilizzato, senza prescrivere un ordine di operazioni. Ciascuna chiamata di accesso è indipendente dalle altre e tutte seguono lo stesso modello, quindi è possibile aggiungere facilmente livelli generici che aggiungono funzionalità senza interrompere il modello di utilizzo previsto.

Al contrario, le interfacce fluide sono spesso progettate per l'uso con un solo colpo: l'oggetto viene creato, viene chiamata una catena di metodi che termina con un metodo che produce un risultato finale e l'oggetto viene quindi abbandonato. C'è molta meno flessibilità (principalmente nei metodi opzionali) e genericità, ma questo è esattamente il vantaggio: l'interfaccia ti costringe a un modello di utilizzo previsto, rendendolo molto facile da usare.

Quindi JavaBeans e le interfacce fluide hanno vantaggi in diversi scenari e che dovresti usare dipende. E potresti anche combinare entrambi.

Bene, poiché la specifica JavaBeans a cui si collega definisce una convenzione per l'accesso alle proprietà, la gente ha deciso di sfruttare la convenzione e ha costruito dei framework attorno ad essa. Alcuni di questi quadri, come Hibernate, erano piuttosto utili e quindi divennero molto popolari. Quindi, poiché le persone usavano framework basati sulle specifiche JavaBeans, javaBeans divenne sempre più onnipresente e intorno a loro vennero costruiti sempre più framework.

Le interfacce fluide sono un'ottima idea, ma giocano bene con Spring o Struts 2? Mi batte.