Java Beans: ¿Arrays asociativos sobreglorificados?

Question

No entiendo la naturaleza de Java Beans tan bien. Bueno, al menos cómo los uso en algunas bases de código que pasan por nuestra tienda.

me encontré con esta pregunta:

Java Beans: What am I missing?

La respuesta aceptada no hace que parezca que los programadores tienden a abusar de Java Bean (que realmente no lo dudo), pero veo que suceda tan a menudo y tan deliberadamente, creo que todavía me estoy perdiendo algo.

veo código que se parece a:

public class FooBean { 
    private int a; 
    private int b; 
    private int c; 

    public int getA() { return a; } 
    public int setA(int x) { a = x; } 

    // etc... 
} 

Ninguna otra estructura o el control de los captadores y definidores. ¿Existe algún tipo de truco de compilación súper genial que involucre reflexión, getters y setters, y la necesidad de algunas matrices asociativas estáticas (pero compiladas) muy torpes?

O tal vez estoy completamente falta el punto. : \

¡Salud!

Editar:

Definitivamente no es promover la idea de campos públicos, aquí.

Answer 1

En realidad, sí, está sucediendo la magia.

Es un modelo realmente tonto, pero los beans GUI (que son todos los componentes) estaban pensados ​​para ser analizados de forma reflexiva por un constructor de GUI. Los campos public set/get están destinados a ser "Propiedades" con los que el usuario pueda trabajar mientras construye su GUI.

Editar: En defensa del sol, debo decir que aunque el patrón resultó ser bastante desagradable debido a todas las personas que lo copiaron y comenzaron a usarlo a través de su código no-frijol, permitió a las personas integrar clases con un constructor de GUI sin usar ningún metadato externo.No necesitaba ningún archivo XML o archivo de propiedades para el editor, era tan fácil como extender el botón y colocar su nuevo objeto en el palet.

Este patrón se ha utilizado en otros lugares y, como habrás notado, es prácticamente lo mismo que tener campos públicos. Creo que es uno de los peores patrones que creó Sun al configurar Java, pero no hubo otras soluciones obvias (creo que todo el concepto fue añadido por las primeras personas que intentaron construir los primeros constructores de GUI antes del lanzamiento de Java).

Ahora hay una solución mucho mejor: al usar anotaciones para marcar campos privados, una herramienta reflexiva aún podría analizarlos y vincularlos a los controles del generador. Esto sería mucho más limpio y no haría que todos sus objetos sean tan vulnerables a los cambios de estado externos.

Answer 2

'getters' y 'setters' son excelentes si desea anular el acceso a sus datos, por ejemplo, para iniciar sesión/seguridad o devolver un valor diferente de la clase original.

Answer 3

Las personas abusan del uso de getter/setters tontos, sin lugar a dudas.

Sin embargo, imaginar la cantidad de dolor que tiene que ir a través de 2 años en el camino, cuando te das cuenta de hay que pelar withespaces fuera de la cadena en el método de setEmail(string email); y todo el código está acoplada difícil de usar campos públicos en lugar de una llamada de método

Recuerde una de las principales reglas del diseño orientado a objetos "Código para una interfaz, no una implementación". El acceso a los campos públicos de una clase es ciertamente el último, y hará que el código de refactorización sea mucho más difícil.

Answer 4

sin un regulador que no se puede comprobar si hay invariantes:

public void setFoo(Foo foo) { 
    if (foo == null) { 
      throw new InvalidFoo(); 
    } 

    this.foo = foo; 
} 

con los miembros del público que no puedes hacer eso. Segundo punto, dentro de un setter puedes disparar eventos que otros beans pueden escuchar. Por último, pero no menos importante, puede hacer cumplir la verificación de tipos adecuada (como señaló en su pregunta).

Answer 5

Java Beans son, como usted señala, una convención de codificación bastante trivial.

La parte útil es que eran una convención en absoluto. Esto permitió que se construyeran herramientas auxiliares basadas en (en ese momento) ideas novedosas como especificar exactamente cuál era el nombre de getters y setters, y la expectativa de que existirían métodos específicos sin necesidad de adscribirse a una interfaz. Esto le permitió flexibilidad suficiente para hacer lo que quisiera, pero aún le permitió usar la GUI para ensamblar beans.

En este punto, con la introspección completa siendo la norma, y ​​otros lenguajes que tienen funcionalidad get/set formalizada, y muchas otras maneras de hacer lo que Beans hacen, creo que son una idea cuyo tiempo ha pasado.

Answer 6

No te estás perdiendo el punto. Los Getters/Setters son feos, pero están integrados en tantas herramientas que hacen suposiciones sobre nombres de clase/método/campo (por ejemplo, primavera) que (aparte de su valor obvio para la encapsulación) se han convertido en un requisito cercano, a menos que sea trabajando en un contexto limitado y privado de muy.