¿Cuál es la forma correcta de escribir un setter? [cerrado]

7

Estoy tratando de aprender JAVA por mi cuenta. En un libro que estoy leyendo, el autor dice que no hay ninguna convención para escribir un setter correcto. Su ejemplo sería algo como esto:

public void setUnitCost(double inUnitCost) {
     unitCost = inUnitCost;
}

Sin embargo, cuando uses Eclipse, y dile a los creadores y creadores que haga esto:

public void setUnitCost (double unitCost){
     this.unitCost = unitCost;
}

Mi pregunta es ¿cuál es la mejor manera? ¿Hace una diferencia en el mundo de la programación? ¿Cuál es exactamente la diferencia entre los dos?

    
pregunta Tim Schoell 19.02.2012 - 04:05

11 respuestas

15

No hay diferencia significativa. Ambos producen el mismo resultado.

Personalmente prefiero la versión de Eclipse, ya que encuentro:

  • Es más elegante que el nombre en la lista de parámetros sea el mismo que el campo utilizado internamente en el objeto.
  • Tener el nombre del parámetro unitCost se ve y funciona mejor al completar el código que inUnitCost o similar (ya que también es probable que uses el nombre unitCost en el código de llamada).
  • Es bueno ser explícito sobre el hecho de que está configurando un campo con el this . El reconocimiento de mi patrón de código aquí inmediatamente dice "ah ... esta línea está configurando un campo en el objeto actual".

Pero eso es, en última instancia, solo una elección de estilo.

    
respondido por el mikera 19.02.2012 - 04:46
5

No hay una diferencia significativa entre los dos.

La diferencia (aparte del espacio en blanco) es que uno usa explícitamente this para establecer el nuevo valor. Que yo sepa, no hay ninguna ventaja o desventaja en hacer eso.

    
respondido por el Josh K 19.02.2012 - 04:14
5

Es solo una elección de estilo. Algunos programadores se molestan al tener que inventar nombres estúpidos como inUnitCost o newUnitCost para los parámetros de la función. Algunos se molestan al tener que notar que el símbolo unitCost del parámetro de función reemplaza el símbolo unitCost para el miembro objeto. Debes mantener el consenso que alcances con tus colegas.

    
respondido por el Karl Bielefeldt 19.02.2012 - 04:46
3

Es probable que el primer ejemplo se vea en algunos círculos como una mala convención, ya que hace que el valor de entrada parezca estar en notación húngara.

Muchas herramientas para completar y dar formato al código lo alentarán a usar this para ser explícito en el uso de las variables. Tiendo a estar de acuerdo con esto, ya que deja muy claro de un vistazo si la variable es local o pertenece a la clase. Por supuesto, si mantiene todos sus métodos agradables y cortos en el orden de unas pocas líneas, y las listas de parámetros de los métodos también son bastante cortas, entonces no necesariamente será un problema para usted. Personalmente, todavía prefiero ver this generosamente rociado alrededor del código, ya que esto hace que las variables destaquen claramente debido al resaltado de sintaxis que los IDE más modernos le brindan, y cuanto menos tengo que mirar demasiado profundamente en el código, menos me distraigo al saltar alrededor del código al intentar resolver problemas lógicos complejos en mi cabeza.

Con eso dicho, el compilador no se preocupará de qué manera has escrito tus configuradores. Por otra parte, sus colegas pueden tener opiniones diferentes, por lo que depende de todos ustedes decidir qué enfoque desea incluir en un estándar de codificación.

    
respondido por el S.Robins 19.02.2012 - 07:23
2

Como una herramienta de generación automática de código, el generador de Eclipse no está necesariamente sujeto a las mismas reglas que rigen lo que vale la pena para los programadores humanos. No lo olvides.

Sin embargo, los dos son completamente equivalentes en este caso.

    
respondido por el DeadMG 19.02.2012 - 04:15
2

El código idiomático más moderno sería:

public void setUnitCost(final double unitCost)
{
     this.unitCost = unitCost;
}
  1. marcar el argumento final es importante; el uso de JSR305 @ Nonnullable / @ Nullable cuando se trabaja con referencias de objetos es incluso mejor para documentar las intenciones del código.
  2. this. es autodocumentado de que está configurando la instancia actual y no una variable en una superclase, que debería usar super. idiomáticamente
respondido por el Jarrod Roberson 19.02.2012 - 09:39
1

No hay diferencia entre ellos. Mientras cumpla con su tarea de manera eficiente, está bien. Yo escribo mis Setters (a veces) de esta manera

public void setFoo(String fooName){
  this.fooName = fooName;
}

La razón por la que usé esto es que me falta la idea de nombrar correctamente las variables. Pero no obstante, puedes escribir un setter que te convenga.

Pero prefiero el primer setter, ya que pueden ocurrir errores en el segundo

    
respondido por el user962206 19.02.2012 - 11:57
0

Esto podría rozar a algunas personas de manera incorrecta, pero yo diría que no escriba (o genere) código que simplemente obtenga o establezca una variable, ya que genera desorden y más líneas de código para leer / escanear para comprender. lo que hace tu clase Este desorden puede desviar la atención del código que en realidad tiene detalles de implementación específicos que no sean simplemente obtener o establecer una variable.

La biblioteca Lombok proporciona @Getter & @Setter anotaciones para evitar que tenga que escribir (y otros para leer) los métodos 'tontos' de getter y setter. En el momento de la compilación, Lombok generará estos métodos para usted, y su integración IDE significa que no notará la diferencia cuando se desarrolle.

(Incluso hay una opción de-lombok para generar código fuente con los getters y setters adecuados en su lugar, sin ninguna dependencia de Lombok, pero no lo recomendaría a menos que tenga que cumplir con algunos requisitos realmente extraños). / p>     

respondido por el Tim 19.02.2012 - 12:14
0

En realidad no importa. Nadie mirará el código fuente de tu setter si es así de trivial, así que a nadie le importa qué método estás usando.

    
respondido por el gnasher729 16.03.2017 - 12:50
-1

Yo diría que uno siempre debería preferir

public void setUnitCost (double unitCost){
     this.unitCost = unitCost;
}

en el código de Java. Parece ser la convención que la mayoría de los desarrolladores de Java siguen. Al menos la mayoría de los códigos Java que he visto en los últimos 15 años están escritos de esta forma. Eso es código de varias bases de código, empresas, proyectos, fragmentos de código y ejemplos. No seguir las convenciones no es malo en sí mismo, pero por lo general es una causa de fricción (en este caso, ofenderá ligeramente el reconocimiento de patrones de un cerebro Java entrenado), y debería justificarse con una ganancia significativa, que no veo aquí.

Otro punto sería que el prefijo de variables / parámetros con contexto semántico (notación húngara, entrada / salida para parámetros de entrada / salida, etc.) está ampliamente desaconsejado en toda la comunidad de programación, en la actualidad. Estos prefijos tienen una tendencia a mentir después de algunas refactorizaciones. Los configuradores son lo suficientemente simples, que es seguro decir que el parámetro siempre será un parámetro interno (de lo contrario, ya no sería un definidor, ¿verdad?). Sin embargo, debe tener la misma convención para los nombres en toda la base de código, incluidos los configuradores.

    
respondido por el Patrick Peer 17.03.2017 - 10:11
-2

Algo que no se mencionó en las otras respuestas, el lenguaje común

this.unitCost = unitCost;

será un error difícil de detectar si olvida el this solo una vez en una base de código.

Declarar el parámetro como final puede parecer un resguardo, pero en la práctica, la mayoría de los programadores le permiten al IDE hacerlo automáticamente y, por supuesto, no lo hará una vez que tenga la línea unitCost = unitCost; en su código.

Por lo tanto, veo una buena razón para usar el primer idioma, es decir, hacer que el nombre del parámetro y el campo sean diferentes:

unitCost = pUnitCost; //p for parameter
    
respondido por el Roland 16.03.2017 - 07:57

Lea otras preguntas en las etiquetas