java - make - Ventaja de establecer y obtener métodos vs variable pública

private class java

Question

Posible duplicado:
¿Por qué usar getters y setters?

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

Por ejemplo, ¿el segundo caso es 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;
    }

}

Answer 1

1. Algunas bibliotecas requieren que esto cumpla 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 descendidas.
4. setters / getters abstraen la información, ya sea que un valor se calcule a pedido o solo un acceso a una propiedad

Answer 2

El uso de una variable pública puede causar la configuración de valores incorrectos a la variable ya que el valor de entrada no se puede verificar .

p.ej:

 public class A{

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

   }

El uso de setter se puede usar para configurar la variable al verificar la entrada . Mantener la instancia varibale private, y getter and setter public es una forma de encapsulation getter y setter también es compatible con Java Beans estándar ,

getter and setter también ayuda a implementar el concepto de polimorfismo

p.ej:

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órfico: Podemos asignar 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");

             }
         }
      }

Answer 3

Lo que he visto algún día en SO, como respuesta (escrito por @ ChssPly76) por qué usar getters y setters

Debido a que 2 semanas (meses, años) a partir de ahora, cuando se dé cuenta de que su incubadora necesita hacer algo más que establecer el valor, también se dará cuenta de que la propiedad se ha utilizado directamente en otras 238 clases :-)

hay muchas más ventajas:

1. getters y setter pueden tener validación en ellos, los campos no pueden
2. Usando getter puedes obtener la subclase de la clase deseada.
3. getters y setters son polimórficos , los campos no son
4. la depuración puede ser mucho más simple, porque el punto de corte se puede colocar dentro de un método que no está cerca de muchas referencias de ese campo dado.
5. pueden ocultar los cambios de implementación :

antes de:

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 ventaja adicional cuando estás usando Eclipse: puedes crear un punto de observación en el campo, pero si tienes un setter necesitas solo un punto de interrupción, y ... los puntos de ruptura (por ejemplo, en el método setter) pueden ser condicionales, puntos de observación (en el campo) no puedo Entonces, si quiere detener su depurador solo si x=10 puede hacerlo solo con un punto de interrupción dentro de setter.

Answer 4

Una forma algo retrospectiva de mirar las cosas.

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

Una especie de respuesta en sí misma realmente ¿no es así?

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