¿Por qué los métodos de acceso de la especificación JavaBean se han convertido en el estándar para el desarrollo de Java?

9

La especificación JavaBeans describe un JavaBean como

Un Java Bean es un componente de software reutilizable que se puede manipular visualmente en una herramienta de creación.

Dado que la mayoría de las líneas de código que se escriben parecen no tener nada que ver con ser manipuladas visualmente en una herramienta de creación, ¿por qué la especificación JavaBean ha sido la "forma" de escribir código orientado a objetos?

Me gustaría renunciar al getter / setter tradicional a favor de Fluent Interfaces en todo el código, no solo en los constructores, sino que temo hacerlo, ya que tradicionalmente no es la forma en que el código orientado a objetos está escrito en Java.

java history

— Dakotah North
fuente

¿Porque se puede manipular visualmente en una herramienta de construcción? Solo adivinando. Nada, por supuesto, le impide usar interfaces fluidas en todas partes, si así lo desea. El crisol de la experiencia te golpeará en la cabeza si eso resulta ser una mala idea.

— Robert Harvey

7

Los accesores de estilo JavaBean han demostrado ser una buena combinación para todo tipo de escenarios que son similares al escenario original de la "herramienta de creación" en un punto central: los componentes se pasan y manipulan mediante contenedores y herramientas genéricos, así como el código de la aplicación. En un servidor de aplicaciones, tiene componentes de servicio a los que un contenedor EJB o Spring agrega transacciones e inyecciones de dependencia, modelos de dominio persistentes a los que un ORM agrega carga lenta y detección de cambios, y que una biblioteca puede serializar en XML sin ningún código específico.

Los accesores proporcionan una API común que es muy flexible en la forma en que se puede usar el componente; no prohíbe un orden de operaciones. Cada llamada de acceso es independiente de otras y todas siguen el mismo patrón, por lo que puede agregar fácilmente capas genéricas que agregan funcionalidad sin interrumpir el patrón de uso previsto.

En contraste, las interfaces fluidas a menudo se diseñan para un uso único: se crea el objeto, se llama una cadena de métodos que termina con un método que produce un resultado final, y luego se abandona el objeto. Hay mucha menos flexibilidad (principalmente en los métodos que son opcionales) y genérico, pero esta es exactamente la ventaja: la interfaz lo obliga a un patrón de uso previsto, lo que lo hace muy fácil de usar.

Por lo tanto, JavaBeans y las interfaces fluidas tienen ventajas en diferentes escenarios, y lo que debe usar depende. E incluso podrías combinar ambos.

— Michael Borgwardt
fuente

3

Bueno, debido a que la especificación JavaBeans a la que se vincula define una convención para acceder a las propiedades, la gente decidió aprovechar la convención y crear marcos a su alrededor. Algunos de estos marcos, como Hibernate, fueron bastante útiles y se hicieron muy populares. Entonces, debido a que las personas usaban frameworks que se basaban en la especificación JavaBeans, javaBeans se volvió cada vez más ubicuo, y se construyeron más y más frameworks alrededor de ellos.

Las interfaces fluidas son una gran idea, pero ¿funcionan bien con Spring o Struts 2? Me gana

— Matthew Flynn
fuente