Por que os métodos acessadores da especificação JavaBean se tornaram o padrão para o desenvolvimento Java?

A especificação JavaBeans descreve um JavaBean como

Um Java Bean é um componente de software reutilizável que pode ser manipulado visualmente em uma ferramenta de construção

Como a maioria das linhas de código escritas parece não ter nada a ver com a manipulação visual de uma ferramenta construtora, por que a especificação JavaBean tem sido a "maneira" de escrever código orientado a objetos?

Eu gostaria de renunciar ao getter / setter tradicional em favor das interfaces fluentes em todo o código, não apenas nos construtores, mas receio fazê-lo, já que esse não é o modo tradicional como o código orientado a objetos é escrito em Java.

Os acessadores no estilo JavaBean provaram ser uma boa combinação para todos os tipos de cenários semelhantes ao cenário original da "ferramenta construtora" em um ponto central: os componentes estão sendo passados ​​e manipulados por contêineres e ferramentas genéricas, bem como pelo código do aplicativo. Em um servidor de aplicativos, você tem componentes de serviço nos quais um contêiner EJB ou Spring adiciona transações e injeções de dependência, modelos de domínio persistentes nos quais um ORM adiciona carregamento lento e detecção de alterações e que podem ser serializados em XML por uma biblioteca sem código específico.

Os acessadores fornecem uma API comum que é muito flexível na maneira como o componente pode ser usado - ele não proíbe uma ordem de operações. Cada chamada do acessador é independente das outras e todas seguem o mesmo padrão, para que você possa adicionar facilmente camadas genéricas que adicionam funcionalidade sem interromper o padrão de uso pretendido.

Por outro lado, as interfaces fluentes costumam ser projetadas para uso único: o objeto é criado, uma cadeia de métodos é chamada que termina com um método que produz um resultado final e o objeto é abandonado. Há muito menos flexibilidade (principalmente nos métodos opcionais) e generosidade, mas essa é exatamente a vantagem: a interface o força a adotar um padrão de uso pretendido, facilitando o uso.

Portanto, o JavaBeans e as interfaces fluentes têm vantagens em diferentes cenários, e o qual você deve usar depende. E você pode até combinar os dois.

Bem, como a Especificação do JavaBeans ao qual você vincula define uma convenção para acessar propriedades, as pessoas decidiram tirar proveito da convenção e criaram estruturas em torno dela. Algumas dessas estruturas, como o Hibernate, foram bastante úteis e, portanto, tornaram-se muito populares. Portanto, como as pessoas usavam estruturas baseadas nas especificações do JavaBeans, o javaBeans se tornava cada vez mais onipresente e cada vez mais estruturas eram construídas em torno delas.

Interfaces fluentes são uma ótima idéia, mas elas funcionam bem com Spring ou Struts 2? Me bate.