¿En qué orden definir getters y setters? [cerrado]

14

¿Existe una práctica recomendada para que la orden defina captadores y establecedores? Parece que hay dos prácticas:

  • pares getter / setter
  • primero getters, luego setters (o al revés)

Para iluminar la diferencia, aquí hay un ejemplo de Java de pares getter / setter:

public class Foo {
    private int var1,
    var2,
    var3;

    public int getVar1() {
    return var1;
    }

    public void setVar1(int var1) {
    this.var1 = var1;
    }

    public int getVar2() {
    return var2;
    }

    public void setVar2(int var2) {
    this.var2 = var2;
    }

    public int getVar3() {
    return var3;
    }

    public void setVar3(int var3) {
    this.var3 = var3;
    }
}

Y aquí hay un ejemplo de Java de primero getters, luego setters:

public class Foo {
    private int var1,
    var2,
    var3;

    public int getVar1() {
    return var1;
    }

    public int getVar2() {
    return var2;
    }

    public int getVar3() {
    return var3;
    }

    public void setVar1(int var1) {
    this.var1 = var1;
    }

    public void setVar2(int var2) {
    this.var2 = var2;
    }

    public void setVar3(int var3) {
    this.var3 = var3;
    }
}

Creo que el último tipo de ordenamiento es más claro tanto en el código como en los diagramas de clase, pero no sé si eso es suficiente para descartar el otro tipo de ordenamiento.

NN
fuente

Respuestas:

8

La primera manera Si es posible, siempre agrupe o manténgase cerca de las funciones relacionadas que operan en los mismos miembros.

Si organiza su código de esta manera, lo hace más claro y fácil de refactorizar, ya que si una clase se puede factorizar a partir de otra que está haciendo demasiado, la pieza factorizable generalmente gira en torno a una variable miembro específica.

En general, es más fácil depurar, comprender y manipular el código cuando puede ver todo en la misma página durante todo el ciclo de vida de un objeto / variable. Llegaría al extremo de decir que el diseño del Código basado principalmente en superficialidades como el alcance y el orden alfabético significará que perderá oportunidades para refactorizar porque no puede verlos.

Benedicto
fuente
¿Desea incluir algún argumento adicional sobre por qué las funciones que operan en los mismos miembros deben mantenerse juntas?
NN
Se agregaron algunas razones.
Benedict
25

Si está en un equipo, haga lo que suelen hacer. De lo contrario, simplemente elige el que más te guste. En la escala de opciones de diseño importantes, esto probablemente se encuentre cerca de "¿qué pulgar debo usar para presionar la barra espaciadora?"

axblount
fuente
77
De acuerdo completamente. Esto viene bajo el título de "no te preocupes por las cosas pequeñas", que debería ser la regla estándar de codificación # 0 de todos ( es la regla # 0 en "Normas de codificación C ++" de Herb Sutter y Andre Alexandrescu.)
David Hammen
Estoy seguro de que la gente ha discutido mucho sobre qué pulgar deberían usar para presionar la barra espaciadora)))
superM
@Michael Yo también soy un derecho. Intenté usar exclusivamente mi izquierda, pero fue extremadamente difícil y mi escritura se ralentizó.
axblount
@axblount Soy diestro, pero siempre uso mi pulgar izquierdo. Acabo de probar mi derecho y tuve la misma experiencia que describiste. También escribo "y" con la mano izquierda por alguna razón.
KChaloux
6

También puede depender del idioma. En Java no hay ninguna ventaja real para ninguno de los dos pedidos, pero en C #, por ejemplo, tiene el concepto de "propiedades", que agrupa el captador y el establecedor, por lo que impone ese orden. En un lenguaje como C ++, donde es posible que desee una visibilidad diferente en getters versus setters (por ejemplo, setter privado, getter público), probablemente haría lo contrario, ya que el modificador de visibilidad se proporciona una vez para múltiples métodos, en lugar de individualmente para cada uno .

Darrel Hoffman
fuente
5

Que yo sepa, no existe una convención única. La sección Convenciones de código Java de Oracle sobre organización de archivos no menciona explícitamente la ubicación de captadores y establecedores, pero dice:

Estos métodos deben agruparse por funcionalidad en lugar de por alcance o accesibilidad.

Esto no proporciona ninguna orientación; podría argumentar que cualquiera de las ubicaciones cumple con este criterio.

Algo a considerar es que los IDEs modernos le permiten tener vistas más abstractas de la estructura de sus archivos que como el componente de código textual. Esto, junto con potentes herramientas de búsqueda, debería facilitar la navegación por los archivos y encontrar los métodos adecuados incluso en archivos grandes.

Como ejemplo, Eclipse proporciona una vista de esquema que le permite ordenar y filtrar métodos y campos de diferentes maneras, y navegar directamente a donde están en los archivos. NetBeans tenía una funcionalidad similar, y sospecho que la mayoría de los otros IDE también lo hacen.

El único momento en que esto podría importar es si está leyendo el código fuera de su IDE. Un ejemplo podría ser usar una herramienta de revisión de código externa o ver deltas desde su sistema de control de versiones.

La mejor solución sería simplemente ser coherente entre los archivos de un proyecto. Encuentre un estándar, documente y cúmplalo.

Thomas Owens
fuente
1

Agrupe al captador y al colocador para un solo campo, en pares.

Agrupar a todos los captadores juntos y a todos los establecedores juntos hace que sea difícil saber qué campos tienen solo captadores o solo establecedores.

Cuando leo código o busco una funcionalidad específica, imagino que una clase tiene campos, y cada campo tiene un captador y un establecedor. Para mí no tiene sentido que una clase tenga un grupo getters y un grupo setters, cada uno con campos.

M. Dudley
fuente
Entonces, ¿su argumento es que los captadores para un campo deben emparejarse con los captadores para ese campo porque facilita la descripción general de cómo se manejan ciertos campos en una clase?
NN
Eso y el modelo conceptual de lo que es una clase. Las clases deben organizarse principalmente por funcionalidad. Al crear una clase, puede decidir que necesita un campo mutable visible públicamente. Esa es la "funcionalidad" conceptual, no la expresión sintáctica a través de los métodos getter y setter.
M. Dudley
0

Ever Java IDE puede generar captadores y establecedores para usted. Simplemente use esa funcionalidad y deje el orden de esos métodos como el IDE lo creó. Este es un código generado, no lo toques innecesariamente.

usuario281377
fuente
Estoy consciente de esto. Sin embargo, por ejemplo, en Eclipse puede elegir entre diferentes ordenamientos .
NN
Correcto. La opción predeterminada "Campos en pares getter / setter" parece más útil, porque puede agregar más campos y generar más accesores más tarde sin tener que preocuparse de qué método va a dónde, simplemente coloque ambos al final.
usuario281377