Mutability and Spring

Actualmente estoy volviendo a leer "Effective Java" mientras trabajo en una tienda que hace un uso intensivo de Spring Dependency Injection. Al leer el libro de Bloch no se puede dejar de destacar el énfasis que pone en la inmutabilidad en las clases (afirma varias veces que las clases deben ser tan inmutables como sea posible). No puedo evitar sentir esto en conflicto directo con la confianza que Spring Dependen Injection (y la mayoría de los motores de DI para ese hecho) tienen en el estándar JavaBeans. Al leer 'Spring in Action', los capítulos de DI parecen hacer que Bloch se encoja con sus clases mutables compuestas de objetos instanciados fuera de su ámbito que podrían ser mutables por derecho propio.Mutability and Spring

¿Las ideas de Bloch son demasiado novedosas para Spring? ¿El modelo de Spring está reventado? ¿La postura de Bloch sobre la inmutabilidad solo se aplica a la escritura del código de la biblioteca? Al escribir el código de Spring, ¿debo escribir objetos flexibles con muchos getters y setters o cargar todo en el constructor?

Fuente

2011-04-20 nsfyn55

Bloch no dice "nunca hagas las cosas mutables", dice "no las hagas más mutables de lo necesario". Si su marco necesita un cierto nivel de mutabilidad, entonces es con lo que tiene que vivir. – skaffman

Bien en el ítem relacionado con la mutabilidad, los constructores telescópicos y el patrón del constructor él trastoca el estándar Javabeans (refiriéndose a él como desactualizado), pero ese estándar es la base de Spring ¿significa que la primavera está desactualizada? – nsfyn55

spring no confía en el estándar javabeans. – Bozho

De hecho, los granos de primavera son inmutables por idea, a pesar de que no está haciendo cumplir esto.

Puede proporcionar solo un getter a un campo final que se inicializa mediante la inyección del constructor.

Normalmente no lo hace, pero nunca se supone que debe reasignar campos de frijoles inyectados por el marco DI. Esto se debe a que los beans de primavera generalmente no tienen ningún estado, aparte de sus dependencias (y su alcance es único). Por supuesto, hay excepciones, como el prototipo y los beans de ámbito solicitado, que estos son raros (por ejemplo, en 2 proyectos grandes y 2 medianos, he usado solo 1 prototipo de frijol)

Fuente

2011-04-20 14:48:50 Bozho

Acepto: la mayoría de los objetos instanciados por Spring son "singleton" y no realmente "mutables" (servicios, daos, controladores, transactionManagers, ...). – Tristan

Si inserto un objeto mutable en un campo final que no impide que ese objeto cambie, lo que da como resultado un gráfico de objetos frágiles – nsfyn55

@ nsfyn55, depende totalmente de usted qué objeto inyectar. No tiene nada que ver con DI. – Bozho

Puedes mantener las clases inmutables y aún use Dependency Injection si usa inyección basada en el constructor. De esa forma puedes evitar setters innecesarios.

Fuente

2011-04-20 14:49:06

No veo el conflicto yo mismo, especialmente con Spring MVC. ¿Qué frijoles maneja Spring? Principalmente sus controladores y en su servicio/capa de datos sus DAO y servicios. Por lo general, estos no tienen ningún estado real y tampoco setters. Si su problema radica en la inyección del colocador (por ejemplo, tiene su propia clase que necesita ser administrada por Spring y no desea que setters para ciertos campos), entonces puede usar la inyección de constructor (o combinar ambas).

Fuente

2011-04-20 14:50:10

Respuesta

Cuestiones relacionadas