2011-09-27 13 views
9

El Play! framework generates getters and setters para cada campo público de una clase de modelo en el tiempo de ejecución.¡Benefíciese de getters y setters generados en Play! marco

public class Product { 

    public String name; 
    public Integer price; 
} 

serán transformados a

public class Product { 

    public String name; 
    public Integer price; 

    public String getName() { 
     return name; 
    } 

    public void setName(String name) { 
     this.name = name; 
    } 

    public Integer getPrice() { 
     return price; 
    } 

    public void setPrice(Integer price) { 
     this.price = price; 
    } 
} 

El manual explica además:

Luego, cuando se desea tener acceso a una propiedad que sólo puede escribir:

product.name = "My product"; 
product.price = 58; 

que se traduce en el tiempo de carga a:

product.setName("My product"); 
product.setPrice(58); 

... y advierte:

No se puede utilizar directamente los métodos getter y setter para acceder a las propiedades si se basan en la generación automática. Estos métodos se generan en el tiempo de ejecución . Entonces, si los referencia en el código que escribe, el compilador no encontrará los métodos y generará un error.

¡Ya que no puedo usar estos captadores y localizadores desde fuera del Play! proyecto, no veo ningún beneficio en generarlos. ¿Cuál es el beneficio en comparación con los campos públicos, las refactorizaciones (encapsular un campo y cambiar las llamadas) de todos los IDEs modernos que se tienen en cuenta?

Respuesta

8

Respuesta corta: Los frijoles los requieren.

Más: la especificación de Beans requiere (entre otras cosas) getter/setter para cada campo interno. No estoy 100% seguro, pero supongo que tanto las plantillas de Hibernate como las de Groovy esperan Java Beans (¡los POJO Beans, no el Java EE uno!), Por lo que pedirán getters/setters. Jugar solo te ahorra tiempo haciendo eso, para que no tengas que preocuparte por el código de la placa de la caldera (a menos que quieras definir tu propio eliminador/instalador por alguna razón, lo cual puedes hacer).

+0

+1 buena respuesta. Me he expandido sobre el punto de definir sus propios setters y getters ya que creo que es un punto realmente importante. – Codemwnci

8

Otra razón, aunque no es necesario especificar los ajustadores y captadores, ¡todavía puede!

Por lo tanto, si usted tiene (por tu ejemplo)

product.name = "my product" 

Eso está bien, y hace su código más rápido y en mi opinión más fácil de leer. Sin embargo, hay una buena razón para que los setters y getters encapsulen. Si desea agregar algo de lógica cuando se cambia su nombre de producto, puede especificar su propio setter, pero no tiene que cambiar el código anterior, ya que seguirá llamando al colocador detrás de las escenas.

Por lo tanto, esto le da la flexibilidad y la potencia de una buena encapsulación, pero la pulcritud y legibilidad del acceso directo al campo.

Mi opinión, esto es lo mejor de ambos mundos.

+0

¡Pero dado que las "propiedades" están disponibles solo dentro del mismo juego! proyecto podría fácilmente utilizar una refactorización de mi IDE. – deamon

+0

sí, pero luego pierde en la legibilidad. Donde esto realmente ayuda, creo, está en las plantillas. – Codemwnci

0

Si tiene un método getter/setter privado, entonces esto no funcionará, ya que no es posible crear un método público getter/setter con el mismo nombre. ¡Así que fallará en el tiempo de ejecución!

Cuestiones relacionadas