class - ejemplos - lombok spring

¿Es una mala práctica que mi método getter cambie el valor almacenado?

Question

¿Es una mala práctica cambiar mi método getter como la versión 2 en mi clase?

Versión 1:

 public String getMyValue(){
return this.myValue
}

Versión 2:

 public String getMyValue(){
if(this.myValue == null || this.myValue.isEmpty()){
this.myValue = "N/A";
}
return this.myValue;
}

Answer 1

Cambiaría mejor el método setter así que, si el valor es null o está vacío, el N/A se asigna al atributo. Por lo tanto, si usa el atributo en otros métodos dentro de la clase (vg toString() ), tendrá el valor deseado allí.

Alternativamente, cambie el método setter para lanzar una excepción cuando el valor que se está configurando no es correcto, por lo que el programador se ve obligado a mejorar su manejo antes de establecer el valor.

Aparte de eso, está bien.

Answer 2

Creo que en realidad es una mala práctica si sus métodos getter cambian el estado interno del objeto.

Para lograr lo mismo, sugeriría simplemente devolver el "N/A" .

• En términos generales, este campo interno se puede usar en otros lugares (internamente) para los cuales no necesita usar el método getter. Entonces, al final, la llamada a foo.getMyValue() podría cambiar el comportamiento de foo .

Alternativamente, la traducción de null a "N/A" podría realizarse en el colocador , es decir, el valor interno podría establecerse en "N/A" si se pasa null .

Una observación general:
Solo agregaría estados como "N/A" si alguna API u otra instancia esperan su código. Si ese no es el caso, debe confiar en los tipos nulos estándar que están disponibles para usted en su lenguaje de programación.

Answer 3

Creo que es mejor inicializar esto. this.myValue = "N/A" . Y las llamadas posteriores a setMyValue deben modificar this.myValue acuerdo con las condiciones de su negocio.
El getMyValue no debe modificar de ninguna manera this.myValue . Si sus necesidades son devolver cierto valor, debe devolver ese valor (como "N / A") y no alterar this.myValue . this.myValue . Los Getters no deben modificar el valor del miembro.

Answer 4

En mi opinión, a menos que esté haciendo lazy-loading (que no es en ese caso), los getters no deberían cambiar el valor. Entonces yo también:

Pon el cambio en el colocador

public void setMyValue(String value) {
if(value == null || value.isEmpty()){
this.myValue = "N/A";
} else {
this.myValue = value;
}
}

O haga que el getter devuelva un valor predeterminado si el valor no está configurado correctamente:

public String getMyValue() {
if(this.myvalue == null || this.myvalue.isEmpty()){
return "N/A";
}
return this.myValue;
}

En el caso de lazy-loading, donde diría que cambiar tus miembros en un getter está bien, harías algo como:

public String getMyValue() {
if (this.myvalue == null) {
this.myvalue = loadMyValue();
}
return this.myValue;
}

Answer 5

En realidad, esto depende en gran medida del contrato que desea aplicar con su método get (). Según las convenciones de diseño por contrato, la persona que llama tiene que asegurarse de que se cumplen las condiciones previas (lo que significa que hacer una validación en un método setter a menudo es un diseño incorrecto) y el llamado (no sé si ese es el término correcto en inglés para eso, es decir, el llamado) se asegura de que se cumplan las condiciones de publicación.

Si define su contrato para que el método get () - no pueda cambiar el objeto, entonces está rompiendo su propio contrato. Piensa en implementar un método como

public isValid() {
return (this.myvalue == null || this.myvalue.isEmpty());
}

La ventaja de este enfoque es que no tiene que comprobar si el retorno de su get () es "N / A" u otra cosa. También se puede invocar esto antes de llamar a set () para validar que no se insertan valores ilegales en su objeto.

Si desea establecer un valor predeterminado, debe hacerlo durante la inicialización.

Answer 6

Haz lo que quieras. Después de todos los getters y setters son solo otros métodos públicos. Podrías usar cualquier otro nombre.

Pero si usa frameworks como Spring , está obligado a usar esos nombres estándar y nunca debe poner sus códigos personalizados dentro de ellos.

Answer 7

Los cambios de estado en getters deberían ser una ofensa colgante. Significa que el código del cliente debe tener cuidado con el orden en que accede a getters y setters y para ello debe tener conocimiento de la implementación. Debería poder llamar a los getters en cualquier orden y obtener los mismos resultados. Se produce un problema relacionado cuando el ajustador modifica el valor entrante dependiendo del estado actual del objeto.

Answer 8

No. Estás haciendo dos cosas aquí. Obteniendo y configurando

Answer 9

Por lo general, defino un getter específico.

Nunca altere el getter original:

 public String getMyValue(){
return this.myValue
}

Y crea un getter específico:

public String getMyValueFormatted(){
if(this.myvalue == null || this.myvalue.isEmpty()){
return "N/A";
}else{
return this.myValue;
}
}

Answer 10

Puede usar algún soporte de valor para este propósito. Como clase opcional en la biblioteca de guayaba.

Answer 11

Sí. es una mala práctica

Por qué ?

Cuando el valor se importa al objeto (en el constructor o en el método setter), ese valor se validará, no se validará hasta que se haya invocado el método getter. Y, si alguien tiene cuidado, crearán un método de validación privado completo para este valor también.

private boolean validateThisValue(String a) {
// return true or false
// in this example will be
if(this.myvalue == null || this.myvalue.isEmpty()){
return false;
}
else {
return true;
}
}
public void setThisValue(String a) {
if (validateThisValue(a)) {
this.myValue = a;
}
else {
// do something else
// in this example will be
this.myValue = "N/A";
}
}

Y, en el método getter, nunca cambie el estado del valor. He trabajado en algún proyecto, y el getter a menudo debe establecerse en const : este método no puede cambiar el estado interno.

Al menos, si no desea esta complicación, en el método getter, debe devolver "N / A" en lugar de cambiar el estado interno, establezca myValue en "N / A".

Espero que esto ayude :)

Answer 12

Siento que esta es una mala práctica a menos y hasta que explique la razón por la cual es tan necesario modificar el objeto dentro del método getter en lugar de hacerlo dentro del método setter.
¿Sientes que esto no se puede hacer por alguna razón? ¿Podrías por favor elaborar?

Answer 13

Un usuario puede modificarlo como parte de la validación, pero un usuario debe devolver el valor y dejar que la persona que realiza la validación realice la validación. Si valida, ¿cómo debería documentarse?

Answer 14

absolutamente sí, es una mala práctica.

Imagine que se comunica a través de la red con un tercero (remoto, COM, ...), esto aumentará el viaje de ida y vuelta y luego el rendimiento de la aplicación.