java - una - ¿Cuál es el objetivo de los getters y setters?

setter and getter java examples

Question

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

He leído libros sobre Java , diciendo que es bueno crear setters y getters para variables como y . Por ejemplo:

public int getX(){
    return x;
}

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

Pero cuál es la diferencia de eso y

...(shape.x)...   // basically getX()

y

shape.x = 90;    // basically setX()

Si los setters y getters son mejores, ¿podría explicarme qué problemas prácticos surgirían?

Answer 1

Antes de entrar en la respuesta, tenemos que saber algo antes ...! " JavaBeans ".
Los JavaBeans son clases de Java que tienen propiedades . Para nuestro propósito, piense en las propiedades como variables de instancia privadas. ya que son privados, la única forma en que se puede acceder desde fuera de su clase es a través de ''métodos'' en la clase.
Los métodos que cambian el valor de una propiedad se llaman métodos setter , y los métodos que recuperan el valor de una propiedad se llaman métodos getter .

Answer 2

Digamos, hipotéticamente, que encuentras una biblioteca que hace un mejor trabajo de lo que has estado haciendo en tu propia clase (YourClass). Lo natural a hacer en este punto es hacer que YourClass sea una interfaz envoltorio para esa biblioteca. Todavía tiene un concepto de "X" que su código de cliente necesita obtener o establecer. Naturalmente, en este punto, prácticamente tiene que escribir las funciones de acceso.

Si omite usar las funciones de acceso y permite que su código de cliente acceda directamente a YourClass.x, ahora tendrá que volver a escribir todo el código de su cliente que haya tocado YourClass.x. Pero si estuvo utilizando YourClass.getX () y YourClass.setX () desde el principio, solo necesitará volver a escribir YourClass.

Uno de los conceptos clave de la programación, y especialmente la programación orientada a objetos, es ocultar los detalles de implementación para que no sean utilizados directamente por el código en otras clases o módulos. De esta forma, si alguna vez cambia los detalles de la implementación (como en el ejemplo anterior), el código del cliente no conoce la diferencia y no tiene que modificarse. Para todo lo que sabe su código de cliente, "x" podría ser una variable, o podría ser un valor que se calcula sobre la marcha.

Esta es una simplificación excesiva y no cubre todos los escenarios donde la implementación de ocultamiento es beneficiosa, pero es el ejemplo más obvio. El concepto de ocultar los detalles de la implementación está muy relacionado con OOP ahora, pero puede encontrar discusiones que se remontan décadas antes de que se idease OOP. Se remonta a uno de los conceptos centrales del desarrollo de software, que es tomar un gran problema nebuloso y dividirlo en pequeños problemas bien definidos que se pueden resolver fácilmente. Las funciones de los accesorios ayudan a mantener sus pequeñas subtareas separadas y bien definidas: cuanto menos conozcan las clases sobre las partes internas de las otras, mejor.

Answer 3

El uso de las funciones getter y setter permite restricciones y encapsulamiento. Digamos que x es el radio. shape.x = -10 no tendría mucho sentido. Además, si alguien intenta establecer un valor ilegal, puede imprimir un error, establecer un valor predeterminado o no hacer nada.

Es una buena práctica hacer que las variables miembro sean privadas para que no puedan ser modificadas directamente por los programas que las usan.

Funciones de mutación
Encapsulation

Answer 4

Esto se hace aplicando el principio de Encapsulation de OOP.

Un mecanismo de lenguaje para restringir el acceso a algunos de los componentes del objeto.

Esto significa que debe definir la visibilidad de los atributos y métodos de sus clases. Hay 3 visibilidades comunes:

• Privado: solo la clase puede ver y usar los atributos / métodos.
• Protegido: solo la clase y sus hijos pueden ver y usar los atributos / métodos.
• Público: cada clase puede ver y usar los atributos / métodos.

Cuando declaras atributos privados / protegidos, te recomendamos crear métodos para obtener el valor (get) y cambiar el valor (set). Un ejemplo de visibilidad es la clase [ArrayList][2] : tiene una propiedad de size para conocer el tamaño real de la matriz interna. Solo la clase debe cambiar su valor, por lo que el código es algo así como

public class ArrayList<E> {
    private int size;
    private Object[] array;
    public getSize() {
        return this.size;
    }
    public void add(E element) {
        //logic to add the element in the array...
        this.size++;
    }
}

En este ejemplo, puede ver que el valor de tamaño solo puede cambiar dentro de los métodos de clase, y puede obtener el tamaño real llamándolo en su código (no mutando):

public void someMethod() {
    List<String> ls = new ArrayList<String>();
    //adding values
    ls.add("Hello");
    ls.add("World");
    for(int i = 0; i < ls.size(); i++) {
        System.out.println(ls.get(i));
    }
}

Answer 5

Getters y setters encapsulan los campos de una clase al hacerlos accesibles solo a través de sus métodos públicos y mantener los valores en privado. Eso se considera un buen principio OO.

Por supuesto, a menudo parece un código redundante si no hace nada más que establecer o devolver un valor. Sin embargo, los setters también te permiten hacer validaciones o limpiezas de entrada. Tener eso en un lugar mejora la integridad de los datos para sus objetos,

Answer 6

Hay muchas razones. Aquí hay solo algunos.

1. Los usuarios, especialmente los buscadores, a menudo aparecen en las interfaces. No puede estipular una variable miembro en una interfaz.
2. Una vez que expone esta variable de miembro, no puede cambiar de opinión acerca de cómo se implementa. Por ejemplo, si luego ve la necesidad de cambiar a un patrón como la agregación, donde quiere que la propiedad "x" provenga realmente de algún objeto anidado, terminará teniendo que copiar ese valor e intentar mantenerlo sincronizado. No está bien.
3. La mayoría de las veces es mucho mejor que no expongas al colocador. No puedes hacer eso con campos públicos como x.

Answer 7

Múltiples razones:

• Si permite el acceso al campo como

  shape.x = 90

entonces no puede agregar ninguna lógica en el futuro para validar los datos.

Digamos que si x no puede ser menor a 100 no puedes hacerlo, sin embargo, si tuvieras setters como

public void setShapeValue(int shapeValue){
  if(shapeValue < 100){
    //do something here like throw exception.
  }
}

• No puede agregar algo como copy on write logic (ver CopyOnWriteArrayList )
• Otra razón es para acceder a campos fuera de su clase. Deberá marcarlos como públicos, protegidos o predeterminados, y así perderá el control. Cuando los datos son muy internos a la Encapsulation clase y en general a la metodología OOPS .

Aunque para constantes como

public final String SOMETHING = "SOMETHING";

permitirá el acceso al campo ya que no se pueden cambiar, por ejemplo, la variable los colocará con getters, setters.

• Otro escenario es cuando quieres que tu clase sea inmutable; si permites el acceso al campo, estás rompiendo la inmutabilidad de tu clase, ya que los valores pueden cambiarse. Pero si diseñas cuidadosamente tu clase con getters y sin setters, mantienes intacta la inmutabilidad.

Aunque en tales casos debe tener cuidado con el método getter para asegurarse de no dar referencias de objetos (en caso de que su clase tenga un objeto como instancias).

Podemos usar las variables privadas en cualquier paquete usando getters y setters.

Answer 8

Mucha gente ha mencionado encapsular los detalles de la implementación, que para mí es la razón más importante para usar getters y setters en una clase. Con esto, también obtendrá una gran cantidad de otros beneficios, incluida la capacidad de descartar y reemplazar la implementación por un capricho sin necesidad de tocar cada parte del código que utiliza su clase. En un proyecto pequeño, no es un gran beneficio, pero si su código termina siendo una biblioteca bien utilizada (interna o pública), puede ser un gran beneficio.

Un ejemplo específico: números complejos en matemáticas . Algunos idiomas los tienen como característica de lenguaje o marco, otros no. Usaré una clase mutable como ejemplo aquí, pero podría ser tan fácilmente inmutable.

Se puede escribir un número complejo en la forma a + bi con partes reales e imaginarias, que se [gs]etRealPart bien a [gs]etRealPart y [gs]etImaginaryPart .

Sin embargo, en algunos casos es más fácil razonar sobre números complejos en forma polar re^(iθ) , dando [gs]etRadius (r) y [gs]etAngle (θ).

También puede exponer métodos como [gs]etComplexNumber(realPart, imaginaryPart) y [gs]etComplexNumber(radius, angle) . Dependiendo de los tipos de argumento, estos pueden o no necesitar nombres diferentes, pero luego el consumidor de la clase puede usar cualquiera que se ajuste a sus necesidades.

Las dos formas son intercambiables; puede convertir fácilmente de uno a otro, por lo que la forma que utiliza la clase para el almacenamiento interno es irrelevante para los consumidores de esa clase. Sin embargo, los consumidores pueden usar cualquier forma. Si eliges el formulario a + bi para la representación interna y expones el uso de campos en lugar de getters y setters , no solo obligarás a los consumidores de la clase a usar ese formulario, sino que tampoco podrás cambiar fácilmente de opinión y reemplazar la representación interna con re ^ (iθ) porque resulta ser más fácil de implementar en su escenario particular. Estás atrapado con la API pública que has definido, que exige que específicamente las partes reales e imaginarias se expongan usando nombres de campos específicos.

Answer 9

Originalmente, el patrón getter / setter se creó para promover un buen diseño orientado a objetos al encapsulating las encapsulating internas de una class desde su interface externa.

• Ocultar la representación interna de la propiedad

esta es la mejor respuesta a su pregunta ¿Por qué usar getters y setters?

Answer 10

Otra buena razón para el usuario getter y setter se puede entender por el siguiente ejemplo

public class TestGetterSetter{
    private String name ;


    public void setName(String name){
        this.name = name ;
    }


    public String getName(String name){
        return this.name ;
    }
}

El objetivo de getters y setters es que solo están destinados a ser utilizados para acceder al varialble privado, que están obteniendo o configurando. De esta forma, proporciona la encapsulación y será mucho más fácil refactorizar o modificar su código más adelante.

Imagine que usa nombre en lugar de su getter. Luego, si desea agregar algo como un valor predeterminado (digamos que el nombre predeterminado es ''Invitado'' si no se configuró antes), entonces tendrá que modificar tanto el captador como la función sayName.

public class TestGetterSetter{
    private String name ;


    public void setName(String name){
        this.name = name ;
    }


    public String getName(String name){
        if (this.name == null ){
            setName("Guest");
        }
        return this.name ;
    }
}

No es necesario que getters y setter comiencen con get y set, solo son funciones de miembros normales. Sin embargo, es una convención hacer eso. (especialmente si usas Java Beans)

Answer 11

Porque estamos utilizando el lenguaje de programación orientado a objetos. Aquí estamos usando ocultación y encapsulación de datos. La variable no debe ser accesible directamente desde fuera del mundo (para lograr ocultar datos), por lo que la crearemos de forma privada.

shape.x

no es correcto. El método getter y setter se utilizan para obtener y establecer el valor de x, que es la forma de lograr la encapsulación.

Answer 12

Una de las mejores razones que puedo pensar para getters y setters es la permanencia de la API de una clase. En idiomas como Python puede acceder a los miembros por su nombre y cambiarlos a métodos posteriores. Debido a que las funciones se comportan de manera diferente a los miembros en Java una vez que accede a una propiedad eso es todo. Restringir su alcance más tarde rompe al cliente.

Al proporcionar getters y setters, un programador tiene la flexibilidad de modificar miembros y comportamientos libremente, siempre y cuando se adhiera al contrato descrito por la API pública.

Answer 13

Yo diría que ni los getters / setters ni los miembros públicos son buenos para el diseño orientado a objetos. Ambos rompen la Encapsulación OOP al exponer datos de objetos al mundo que probablemente no deberían tener acceso a las propiedades del objeto en primer lugar.