propiedades - javabeans tutorial
Java Beans: ¿Qué me estoy perdiendo? (5)
Comparto la idea de que minimizar la mutabilidad es algo bueno. Como ya se señaló, la ventaja de JavaBeans es que son fáciles de manejar por los frameworks.
Para obtener lo mejor de "ambos mundos", creo que una buena opción es usar el patrón de Constructor , modificando ligeramente el Constructor para cumplir con el estándar JavaBeans. Entonces, si necesita una funcionalidad de framework que requiera que su clase cumpla con el estándar JavaBeans, puede usar el Builder en lugar de la clase real.
Me pregunto si me está perdiendo algo sobre Java Beans. Me gusta que mis objetos hagan la mayor inicialización posible en el constructor y que tengan un número mínimo de mutadores. Los frijoles parecen ir directamente en contra de esto y generalmente se sienten torpes. ¿Qué capacidades me estoy perdiendo al no construir mis objetos como Beans?
Me gusta que mis objetos hagan la mayor inicialización posible en el constructor y que tengan un número mínimo de mutadores.
Favorecer objetos inmutables es una sabia elección. Sin embargo, el beneficio de beans es que los frameworks / herramientas / bibliotecas pueden determinar en tiempo de ejecución las propiedades de una clase, sin necesidad de implementar una interfaz en particular.
Por ejemplo, supongamos que tiene una colección de beans Person, y cada bean tiene propiedades como nombre, edad, altura, etc.
Puede ordenar esta colección de granos por nombre (por ejemplo) usando el siguiente código:
Collection<Person> myCollection = // initialise and populate the collection
Comparator nameCompare = new BeanComparator("name");
Collections.sort(myCollection, nameCompare);
La clase BeanComparator sabe cómo extraer la propiedad "name" de cada objeto, porque se sigue la convención de Java Beans, es decir, se ahorra la "sobrecarga" de implementar una interfaz como:
interface Nameable {
public String getName();
public void setName(String name);
}
Otro ejemplo de Spring MVC es un bean que almacena parámetros de URL de solicitud. Esto se puede definir en un controlador web (conocido como ''Acción'' en Struts) como este:
public ModelAndView searchUsers(UserSearchCriteria criteria) {
// implementation omitted
}
Como se espera que UserSearchCriteria sea un JavaBean, si el URL de la solicitud contiene un parámetro como maxItems=6 , el marco Spring ''sabe'' que debe llamar a un método con la firma
void setMaxItems(int maxItems);
En esencia, JavaBeans es simplemente una convención simple que permite que las propiedades de una clase se descubran dinámicamente en tiempo de ejecución (generalmente mediante una herramienta o marco), cuando es incómodo / imposible saber a priori las propiedades que se pueden proporcionar.
Cuando escuchas la palabra "bean", esperas ver un "contenedor" de algún tipo. La idea de un JavaBean de cualquier tipo es proporcionar una convención de interfaz uniforme para los componentes que se pueden agregar y manipular en tiempo de ejecución. Los JavaBeans simples son simplemente el ejemplo más simple de esto: presenta todas las posibilidades de interfaz y es serializable, lo que significa que puede crear instancias del bean, modificarlas, guardarlas y volver a cargarlas.
Hace mucho y mucho tiempo, escribí un editor de Java que contenía una simple "base de datos" que representaba las cadenas de texto, y tenía una "arquitectura plug-in" que usaba beans. Puede agregar comportamiento al editor arrastrando un bean fuera de un contenedor de almacenamiento de beans y soltándolo en el editor; una vez que lo hiciste, el comportamiento (por ejemplo, Cntl-T para transponer caracteres en el cursor) estaba disponible de forma automática en el editor. Los beans tenían una interfaz conocida: sabían cómo pedir al contenedor su estructura de datos, y un método doSomething () --- y el contenedor sabía cargar dinámicamente un archivo de clase, crear una instancia del objeto y establecer su acceso a la base de datos.
Por cierto, no es necesariamente cierto que los usuarios violen la encapsulación; Sin embargo, es cierto que solo por tener un miembro, no es necesario que proporcione los métodos get y set para ello. La especificación JavaBean no está nada clara al respecto; el punto es proporcionar getters y setters para aquellas cosas que deben estar en los objetos "contract".
Después de que la introspección y la reflexión se añadieron al lenguaje y realmente se entendieron, la necesidad de esas convenciones se redujo un poco; a principios de Java, necesitabas una convención para encontrar los métodos.
Parece que estás en el camino correcto. No eres tú a quien le falta el punto de Java Beans, son otros programadores los que están malversándolo.
La especificación de Java Beans fue diseñada para ser utilizada con herramientas visuales. La idea era que un diseñador de aplicaciones podría configurar una instancia de un objeto de manera interactiva, y luego serializar (o generar código) el bean configurado, para que pueda ser reconstruido en tiempo de ejecución; la intención era que no sería mutado en tiempo de ejecución.
Desafortunadamente, muchos desarrolladores no entienden que los accesorios violan la encapsulación . Usan estructuras en lugar de objetos. No ven nada mal con otras clases, incluso otros paquetes, que tienen dependencias en los miembros de datos de una clase.
Por supuesto, en general tendrá la necesidad de configurar instancias de sus objetos. Es solo que esto debería hacerse a través de algún tipo de función de configuración. Puede ser un contenedor de inyección de dependencia, una herramienta visual de estilo "BeanBox", o simplemente leyendo archivos JSON, XML o de propiedades que haya escrito a mano. La clave es que en tiempo de ejecución estos objetos son efectivamente inmutables; los clientes solo invocan sus operaciones, no acceden a sus propiedades.