Java: ¿se debe acceder a las variables de instancia privadas en los constructores a través del método getters and setters?

Question

Sé que se accede a las variables de instancia privadas a través de su método público getters y setters.

Pero cuando genero constructores con la ayuda de IDE, inicializa directamente las variables de instancia en lugar de inicializarlas a través de sus métodos setter.

Q1. Entonces, ¿debería cambiar el código generado por IDE para que los constructores inicialicen esas variables de instancia a través de sus métodos setter?

Q2. En caso afirmativo, ¿por qué IDE no genera código de constructores de esa manera?

============================= EDITADO ================ =======================

• utilizo Eclipse y Netbeans IDE

• es una cuestión general. Pero según lo preguntado por @Lords, ¿la respuesta depende de si nuestro constructor es público o protegido o paquete privado o privado?

Answer 1

Debería nunca llamar a un método no final desde un constructor.Un constructor de clase se usa para inicializar un objeto, y el objeto no está en un estado consistente hasta que el constructor regrese. Si su constructor llama a un método no final que luego es anulado por una subclase, puede obtener resultados extraños e inesperados porque el objeto no se inicializa completamente cuando se llama al método reemplazado.

Considere este ejemplo artificial:

class A { 
    private int x; 

    public A() { 
     setX(2); 
    } 

    public void setX(int x) { 
     this.x = x; 
    } 

    public int getX() { 
     return x; 
    } 
} 

class B extends A { 
    private int number = 10; 

    @Override   
    public void setX(int x) { 
     // set x to the value of number: 10 
     super.setX(number); 
    } 
} 

public class Test { 
    public static void main(String[] args) { 
     B b = new B(); 
     // b.getX() should be 10, right? 
     System.out.println("B.getX() = " + b.getX()); 
    } 
} 

La salida de este programa es:

B.getX() = 0 

La razón es que number miembro de B 's no se ha inicializado en el momento setX se llama, por lo se usa su valor predeterminado de 0.

This article tiene una explicación más completa, al igual que Effective Java.

Answer 2

Eso depende. Si sus setters/getters simplemente acceden a los miembros, debe acceder a ellos directamente. Si también tiene algún código junto con él, use setters.

Answer 3

Debería decidir qué campos inicializará con el constructor y cuáles initalizar con un setter. (ambos son posibles) Prefiero usar el constructor solo tanto como sea posible y muchas veces no tengo setters.

Esto debería ser configurable/seleccionable en IDE. Sin conocer su IDE no hay forma de saber por qué funciona de la manera en que lo hace.

Answer 4

Los constructores son para la inicialización. Inicializa variables de instancia privadas directamente en el constructor. Los métodos definen el comportamiento de un objeto. El comportamiento ocurre después de la instanciación/inicialización. Manipule el estado de sus variables de instancia con sus métodos setter. Ese es el pensamiento OOP clásico y probablemente por qué su IDE genera el código que tiene.

Answer 5

Buenas respuestas. Solo quiero agregar que Eclipse (el que uso a menudo) tiene plantillas, que puede modificar para generar su código de la manera que desee. Podría ayudar a ajustar el código a sus necesidades.

PS. Prefiero usar setters y getters. Solo como un hábito, mantiene el código coherente, siento que será más fácil de leer para otra persona si mantengo los hábitos en todo el código.

Answer 6

En primer lugar initialization != setters (al menos no siempre)

Pero IDE están jugando bien, con una vez reverenciados JavaBean patrón de diseño Suponiendo cambios de propiedades deberían pasar a través de los emisores.

Por lo tanto, es una cuestión de diseño. Si sus clases representan objetos de valor puro, no hay daños en la inicialización a través de = Pero si sus clases tienen el potencial de convertirse en JavaBean cuyo cambio de propiedad es más que simplemente init o asignación, vaya con set* llamadas.

Answer 7

Las variables de instancia privadas de una clase deben ser (creo que deben ser) declaradas fuera de cualquier constructor de clase. Si pudiera dividir parte de su pregunta en dos partes:

Q1) Si las variables de instancia se inicializan cuando se crea una instancia de una clase, a diferencia de las variables locales, ¿por qué molestarse en hacer un trabajo extra dentro de un constructor de clase determinado (?).

A1) Aunque no necesita inicializar variables de instancia (cadena privada someString, por defecto es nulo y es legal), una razón para hacerlo es que el valor predeterminado asignado por el compilador puede no ser el valor que desea, o peor, incorrecto (que el compilador debería detectar).

Q2) Asumiendo la parte de arriba, ¿cuál es la importancia de get; conjunto; propiedades?

A2) Aparte del hecho de que son fáciles y más elegantes que un método equivalente, las propiedades se pueden utilizar en cualquier momento dentro de su clase (obviamente), se pueden utilizar como asignaciones simples o contener código adicional (alguien ya lo mencionó para validar la información), y finalmente los datos están contenidos dentro de la clase y, por lo tanto, son más fáciles de depurar.

Dicho todo esto, puede que tenga una razón perfectamente válida para hacer las cosas de forma diferente a lo que dice un libro u otra persona. Siempre hay aceptaciones a la "regla (s)", y debe codificar en consecuencia.