Parece que estás malinterpretando el texto.
Ahora estoy de acuerdo con la última, pero en JavaBeans de mi ojo en una lista hace mucho más sentido que los mapas anidados
El texto no menciona mapas anidados como alternativa (yiack)
... deben llamar a los constructores, no ajustarse * métodos, y el objeto debe ser inmutable
Esta es una buena práctica, especialmente útil cuando se trata con hilos.
Pero no podemos decir que el uso de los emisores es baaad o bien, sobre todo cuando un solo hilo está utilizando el objeto. Eso es perfectamente seguro.
No quiero crear un nuevo objeto cada vez que se da nueva información, quiero agregarlo a uno existente.
Eso está bien, siempre y cuando se controle el objeto no existe ningún problema con esto, algunos otros pueden encontrar más fácil simplemente crear un nuevo objeto.
¿Está utilizando JavaBeans para el almacenamiento de datos una mala práctica y debe evitarse, o es perfectamente seguro?
No, no es una mala práctica. No es perfectamente seguro tampoco. Depende de la situación.
El problema con los objetos mutables (no con JavaBeans per se) es utilizar diferentes subprocesos para acceder a ellos.
Tiene que sincronizar el acceso para evitar que un hilo modifique el objeto mientras que otro está accediendo a él.
Los objetos inmutables no tienen este problema, porque, .. bien, no pueden cambiar, y por lo tanto, no tiene que sincronizar nada.
Para asegurarte de que un objeto es inmutable, debes declarar tus atributos como definitivos.
class MyBean {
private final int i;
}
Si desea asignar un valor razonable para MyBean.i tiene que especificar en el constructor:
public MyBean(int i) {
this.i = i;
}
Puesto que la variable es definitiva, no se puede utilizar un regulador. Solo puede proporcionar un getter.
Esto es perfectamente seguro para subprocesos y lo mejor es que no tiene que sincronizar el acceso, porque si dos subprocesos intentan obtener el valor de i, ambos verán siempre el valor asignado en la creación de instancias. no tiene que sincronizar nada
No es una mala práctica o una buena práctica.Debemos tener que trabajar con un solo hilo, incluso en entornos de subprocesos múltiples como servlets.
Si en el futuro hay que hacer frente a múltiples aplicaciones de hilo, es posible considerar el uso de un JavaBean inmutable;)
Por cierto, la alternativa de crear habas inmutables, y aún así proporcionar un montón de emisores está utilizando Builders como :
Employee e = new EmployeeBuilder()
.setName("Oscar")
.setLastName("Reyes")
.setAge(0x1F)
.setEmployeeId("123forme")
.build();
¿Qué se ve muy similar a la setXyz regular utilizada en los granos regulares con el beneficio de la utilización de los datos inmutables.
Si necesita cambiar un valor, se puede utilizar un método de clase:
Employee e = Employee.withName(e, "Mr. Oscar");
que toma el objeto existente, y copiar todos los valores, y establecer una nueva ....
public static EmployeeWithName(Employee e , String newName){
return new Employee(newName, e.lastName, e.age, e.employeeId);
}
Pero, de nuevo, en un solo modelo de hilo es perfectamente seguro usar getters/setters.
PD Lo recomiendo encarecidamente que compre este libro: Effective Java. Nunca te arrepentirás, y tendrás información para juzgar mejores artículos como el que se cita.
JavaBeans no representa tanto un patrón como un lenguaje completo antipatrón. –
puede usar un generador para obtener los beneficios de la inmutabilidad y evitar el constructor súper largo. –
Considera aprender sobre el patrón de construcción. http://en.wikipedia.org/wiki/Builder_pattern. – CoolBeans