una - (no) ¿Propiedades en Java?

set y get en programacion orientada a objetos

Question

Por lo tanto, hasta hace poco me mantuve voluntariamente un Java n00b, y mi primera exposición real provocó una pequeña conmoción: ¡Java no tiene propiedades de estilo C #!

Ok, puedo vivir con eso. Sin embargo, también puedo jurar que he visto el código getter / setter de propiedades en Java en una base de código, pero no recuerdo dónde. ¿Cómo se logró eso? ¿Hay una extensión de idioma para eso? ¿Está relacionado con NetBeans o algo así?

Answer 1

La convención del frijol es escribir código como este:

private int foo;
public int getFoo() {
return foo;
}
public void setFoo(int newFoo) {
foo = newFoo;
}

En algunos de los otros idiomas en la JVM, por ejemplo, Groovy, obtienes propiedades sobresalientes similares a C #, por ejemplo,

int foo

a la que se accede con un .foo simple y aprovecha las implementaciones getFoo y setFoo predeterminadas que puede anular según sea necesario.

Answer 2

La mayoría de los IDE para Java generarán automáticamente un código getter y setter para usted si así lo desea. Hay una serie de convenciones diferentes, y un IDE como Eclipse le permitirá elegir cuál desea usar e incluso le permitirá definir el suyo propio.

Eclipse incluso incluye refactorización automatizada que le permitirá envolver una propiedad en un getter y setter y modificará todo el código que accede a la propiedad directamente, para que use el getter y / o setter.

Por supuesto, Eclipse solo puede modificar el código que conoce; cualquier dependencia externa que tenga se puede romper con dicha refactorización.

Answer 3

Mi experiencia en Java tampoco es muy alta, por lo que cualquiera puede corregirme. Pero AFAIK, la convención general es escribir dos métodos como ese:

public string getMyString() {
// return it here
}
public void setMyString(string myString) {
// set it here
}

Answer 4

Si está utilizando eclipse, tiene la capacidad de generar automáticamente el método getter y setter para los atributos internos, puede ser una herramienta útil y que ahorra tiempo.

Answer 5

Solo estoy lanzando anotaciones Java 5/6 y un procesador de anotaciones para ayudarlo.

Consulte http://code.google.com/p/javadude/wiki/Annotations

La documentación es un poco ligera en este momento, pero la referencia rápida debe transmitir la idea.

Básicamente genera una superclase con los getters / setters (y muchas otras opciones de generación de código).

Una clase de muestra podría verse como

@Bean(properties = {
@Property(name="name", bound=true),
@Property(name="age,type=int.class)
})
public class Person extends PersonGen {
}

Hay muchas más muestras disponibles, y no hay dependencias de tiempo de ejecución en el código generado.

¡Envíame un correo electrónico si lo pruebas y lo encuentras útil! - Scott

Answer 6

Se propuso "Java Property Support" para Java 7, pero no lo hizo en el idioma.

Consulte http://tech.puredanger.com/java7#property para obtener más enlaces e información, si está interesado.

Answer 7

public class Animal {
@Getter @Setter private String name;
@Getter @Setter private String gender;
@Getter @Setter private String species;
}

Esto es algo así como las propiedades de C #. Es http://projectlombok.org/

Answer 8

Del libro de Jeffrey Richter CLR a través de C # : (Creo que estas podrían ser las razones por las que aún no se agregan propiedades en JAVA)

• Un método de propiedad puede arrojar una excepción; el acceso al campo nunca arroja una excepción.
• Una propiedad no se puede pasar como un parámetro de out o ref a un método; un campo puede.
• Un método de propiedad puede llevar mucho tiempo para ejecutarse; el acceso al campo siempre se completa de inmediato. Una razón común para usar propiedades es realizar la sincronización de subprocesos, que puede detener el subproceso para siempre y, por lo tanto, no se debe usar una propiedad si se requiere sincronización de subprocesos. En esa situación, se prefiere un método. Además, si se puede acceder a su clase de forma remota (por ejemplo, su clase se deriva de System.MarshalByRefObject ), llamar al método de propiedad será muy lento, y por lo tanto, se prefiere un método a una propiedad. En mi opinión, las clases derivadas de MarshalByRefObject nunca deben usar propiedades.
• Si se llama varias veces seguidas, un método de propiedad puede devolver un valor diferente cada vez; un campo devuelve el mismo valor cada vez. La clase System.DateTime tiene una propiedad Readonly Now que devuelve la fecha y la hora actuales. Cada vez que consulta esta propiedad, devolverá un valor diferente. Esto es un error, y Microsoft desea que puedan arreglar la clase haciendo de Now un método en lugar de una propiedad. Environment propiedad TickCount es otro ejemplo de este error.
• Un método de propiedad puede causar efectos secundarios observables; el acceso al campo nunca lo hace. En otras palabras, un usuario de un tipo debería ser capaz de establecer varias propiedades definidas por un tipo en cualquier orden que elija sin notar ningún comportamiento diferente en el tipo.
• Un método de propiedad puede requerir memoria adicional o devolver una referencia a algo que no es realmente parte del estado del objeto, por lo que modificar el objeto devuelto no tiene ningún efecto sobre el objeto original; consultar un campo siempre devuelve una referencia a un objeto que se garantiza que forma parte del estado del objeto original. Trabajar con una propiedad que devuelve una copia puede ser muy confuso para los desarrolladores, y esta característica a menudo no está documentada.

Answer 9

Es posible que no necesite los prefijos "get" y "set", para que se vea más como propiedades, puede hacerlo así:

public class Person {
private String firstName = "";
private Integer age = 0;
public String firstName() { return firstName; } // getter
public void firstName(String val) { firstName = val; } // setter
public Integer age() { return age; } // getter
public void age(Integer val) { age = val; } //setter
public static void main(String[] args) {
Person p = new Person();
//set
p.firstName("Lemuel");
p.age(40);
//get
System.out.println(String.format("I''m %s, %d yearsold",
p.firstName(),
p.age());
}
}

Answer 10

Existe un patrón "estándar" para getters y setters en Java, llamado propiedades de Bean . Básicamente, cualquier método que comience con get , sin tomar argumentos y devolver un valor, es un getter de propiedad para una propiedad denominada como el resto del nombre del método (con una letra de inicio en minúscula). Asimismo set crea un setter de un método void con un solo argumento.

Por ejemplo:

// Getter for "awesomeString"
public String getAwesomeString() {
return awesomeString;
}
// Setter for "awesomeString"
public void setAwesomeString( String awesomeString ) {
this.awesomeString = awesomeString;
}

La mayoría de los IDEs de Java generarán estos métodos si los preguntas (en Eclipse es tan simple como mover el cursor a un campo y presionar ctrl-1, luego seleccionar la opción de la lista).

Por lo que vale la pena, la legibilidad que puede usar is y has en lugar de get también propiedades de tipo booleano, como en:

public boolean isAwesome();
public boolean hasAwesomeStuff();

Answer 11

Y recuerde: si está codificando o utilizando clases que solo tienen setters y getters, no está haciendo un desarrollo orientado a objetos, y probablemente no debería preocuparse por el rendimiento. Estos se llaman estructuras, y son parte integrante de la programación de procedimientos estructurados hacia finales de los años ochenta.

Los objetos tenderán a tener ninguno o muy pocos setters y ninguno o muy pocos getters. La mayoría de los métodos realizarán la funcionalidad real asociada con la clase en la que se encuentran. Para visualizar la diferencia, considere un bean que tenga 10 setters y un objeto que tenga un método load (). Uno fomenta la encapsulación y, por lo tanto, será más comprensible y fácil de mantener: el otro se cuelga en la esquina de una calle y puede y es utilizado por cualquier persona, en cualquier lugar.

ADICION: Para aquellos de ustedes que argumentan en contra de esto porque leen en alguna parte que tener funcionalidad en sus entidades es algo malo, ofrezco esta solución simple: envolver (no copiar) la instancia de la entidad en una clase de dominio. Esto combina el código (la clase de dominio) con los datos (la entidad) de modo que el todo ahora es un objeto verdadero. Ponga toda la funcionalidad que opera en los datos de la entidad en la clase de dominio; una vez hecha esto, ninguna otra clase debería necesitar acceso general a la entidad, por lo que no debe exponer esos get y sets, solo exponer la funcionalidad.

Answer 12

Me sorprende que nadie mencionó el proyecto lombok

Sí, actualmente no hay propiedades en java. También faltan algunas otras características.
Pero afortunadamente tenemos un proyecto de lombok que está tratando de mejorar la situación. También se está volviendo más y más popular todos los días.

Entonces, si estás usando lombok:

@Getter @Setter int awesomeInteger = 5;

Este código también generará getAwesomeInteger y setAwesomeInteger . Por lo tanto, es bastante similar a las propiedades implementadas automáticamente por C # .

Puede obtener más información acerca de getters y setters lombok aquí .
Definitivamente deberías verificar otras funciones también. Mis favoritos son:

• val
• NoArgsConstructor, RequiredArgsConstructor, AllArgsConstructor
• Registros!

Lombok está bien integrado con los IDE, por lo que mostrará los métodos generados, como si existieran (sugerencias, contenido de clase, ir a declaración y refactorización).
El único problema con lombok es que otros programadores podrían no saberlo. Siempre puede omitir el código, pero eso es más bien una solución que una solución.