2012-06-17 21 views
29

Duplicar posibles:
Why use getters and setters?ventaja de establecer y obtener métodos vs variable pública

¿Hay alguna ventaja de hacer métodos para acceder a las variables privadas en su clase en lugar de hacer que la variable pública ?

Por ejemplo, ¿es el segundo caso mejor que el primero?

//Case 1 
public class Shoe{ 
    public int size; 
} 

//Case 2 
public class Shoe{ 
    private int size; 
    public int getSize(){ 
     return size; 
    } 

    public void setSize(int sz){ 
     size = sz; 
    } 

} 
+0

posible duplicado de [¿Por qué usar getters y setters?] (Http://stackoverflow.com/questions/1568091/why-use-getters-and-setters) y [getters y setters auto-implementados vs. campos públicos] (http://stackoverflow.com/questions/111461) –

Respuesta

59

Lo que he visto algún día en el SO, como respuesta (escrito por @ ChssPly76) por qué utilizar captadores y definidores

Debido a 2 semanas (meses, años) a partir de ahora cuando se dan cuenta de que su colocador tiene que hacer algo más que ajustar el valor, también se dará cuenta de que la propiedad ha sido utilizada directamente en otras 238 clases :-)

hay muchas más ventajas:

  1. getters y setter pueden tener la validación en ellos, los campos no
  2. pueden usar getter se puede conseguir subclase de la clase deseada.
  3. captadores y definidores son polimórficos, los campos no
  4. son depuración puede ser mucho más simple, debido a punto de interrupción se puede colocar dentro de un método no cerca de muchas referencias de ese campo determinado.
  5. que pueden aplicación ocultar cambios:

antes:

private boolean alive = true; 

public boolean isAlive() { return alive; } 
public void setAlive(boolean alive) { this.alive = alive; } 

después:

private int hp; // change! 

public boolean isAlive() { return hp > 0; } // old signature 
//method looks the same, no change in client code 
public void setAlive(boolean alive) { this.hp = alive ? 100 : 0; } 

EDITAR: una nueva advange adicional cuando se está utilizando Eclipse - te puede crear un punto de observación en el campo, pero si tiene un setter que necesita solo un punto de interrupción, y ... puntos de interrupción (p. en el método setter) puede ser condicional, watchpoints (en el campo) no puede. Por lo tanto, si desea detener su depurador solo si x=10 puede hacerlo solo con un punto de interrupción dentro de setter.

+0

getters y setters las partes buenas (http://pawel-michalski-javnie.blogspot.de/2012) /04/gettery-settery-enkapsulacja-czy.html) nada gracioso ... ¿por qué darle un título en inglés y proceder con un lenguaje extraño? –

+1

@MatthisKohli Lo siento, tienes razón. Eliminé ese enlace. – dantuch

4
  1. Algunas bibliotecas requieren esto para cumplir con el "estándar Java Bean".
  2. Un setter/getter puede estar en una interfaz, una propiedad no puede estar en una interfaz
  3. Setters/getters pueden anularse fácilmente en las clases descendientes.
  4. set/captadores abstraer la información si un valor se calcula sobre la demanda o simplemente un descriptor de acceso a una propiedad
6

Usando variable pública puede provocar el establecimiento de valores incorrectos para la variable como el valor de entrada no se puede comprobar .

por ejemplo:

public class A{ 

    public int x; // Value can be directly assigned to x without checking. 

    } 

Usando setter se puede utilizar para establecer la variable con el control de la entrada de. Mantener la instancia varibale privado y getter y pública colocador es una forma de encapsulación getter y setter también es compatible con Java Beans estándar,

getter y setter también ayuda en implementar polimorfismo concepto

por ejemplo:

public class A{ 

    private int x;  // 


     public void setX(int x){ 

     if (x>0){      // Checking of Value 
     this.x = x; 
     } 

     else{ 

      System.out.println("Input invalid"); 

     } 
    } 

     public int getX(){ 

      return this.x; 
     } 

ejemplo polimórfica: podemos ASSIG n Variable de referencia de objeto del subtipo como argumento desde el método de llamada a la variable de referencia de objeto del parámetro de superclase del método llamado.

public class Animal{ 

     public void setSound(Animal a) { 

      if (a instanceof Dog) {   // Checking animal type 

       System.out.println("Bark"); 

      } 

     else if (a instanceof Cat) {  // Checking animal type 

       System.out.println("Meowww"); 

      } 
     } 
     } 
0

Una forma algo retrógrada de mirar las cosas.

¿Hay alguna circunstancia en la que es mejor exponer el funcionamiento interno de su clase haciendo pública una variable miembro, para que cualquier consumidor de la misma pueda hacer cosas que el diseñador nunca concibió, dando lugar a un banquete de fracaso y una cornucopia de colisiones?

tipo de respuestas en sí mismo realmente que uno no?

principio de Cornerstone de OO, encapsulación. Una variable de miembro público es básicamente variable global con un prefijo ...

+4

Existen buenas razones para no utilizar getters y setters: agilizan el código, dificultan la lectura y violan el principio DRY. De hecho, en los lenguajes con propiedades, es común hacer las cosas públicas (ya que se pueden refactorizar en propiedades más adelante si es realmente necesario). – Antimony

+0

@Antimonio. No es el lugar para un debate, pero no puedo estar de acuerdo, ni siquiera un poco. He visto demasiados casos en los que ese tipo de atajo erm ha causado mucho más trabajo que simplemente refacturar a una propiedad. Mucho mucho mas. –

Cuestiones relacionadas