¿Hay algún beneficio al usar getters/setters dentro de una clase para sus propios campos?

Question

Normalmente, en mis propios proyectos utilizo getters y setters para cualquier acceso de campo, y seguí para hacer lo mismo en mi trabajo. Hace algún tiempo, el líder tecnológico de nuestro proyecto me preguntó por qué estaba haciendo eso y por qué es mejor que simplemente usar los campos ellos mismos (con la opción de declararlos protegidos si necesitaban acceder a ellos por subclases). No pude encontrar una respuesta clara.

Entonces, ¿hay alguna razón para usar getters y setters dentro de una clase para campos propios de la clase, o es mejor usar los campos directamente?

Answer 1

Quiere declararlos como getters y setters públicos, y campos privados. Esto significa que las clases externas (no las subclases) que desean modificar las variables lo hacen a través de los setters, y las obtienen a través de los getters. El beneficio de esto es que si desea controlar cómo o qué condición obtienen o establecer, o si desea agregar información o incluso imprimir depuración, significa que solo tiene que ponerla en los getters y setters.

Hay una muy buena explicación de los beneficios en StackOverflow realidad:

In Java, difference between default, public, protected, and private

Por supuesto, sólo hacer que los métodos cuando son realmente necesarios, y del mismo modo, sólo el público cuando sea necesario por clases externas.

Espero que ayude a la defensa!

Answer 2

La respuesta más obvia es efectos secundarios:

int getCost() 
{ 
    if (cost == null) { 
     calculateCost(); 
    } 

    return cost; 
} 

Si necesita el costo, el uso getCost(). Si desea ver si se ha calculado el costo, use cost.

Answer 3

Esto es parte de la pregunta general de por qué usa getters y setters. Muchos desarrolladores los usan sin embargo, como una cuestión de práctica. Personalmente, solo pongo getters/setters si es necesario.

Le sugiero que haga lo que es más claro/simple para usted.

En general, si puedo agregar fácilmente un getter/setter más tarde si lo necesito, no lo agregaré. Si sería difícil agregarlo más tarde (o si tiene un uso inmediato para ellos), los incluiría.

Answer 4

Si existe una lógica de negocios alrededor de esos valores (o existe la posibilidad de que exista tal lógica), existe la ventaja de usar getters y setters incluso para llamadas internas.

Por ejemplo, su setter puede hacer la validación en sus entradas, y lanzar una excepción en lugar de almacenar un valor no válido. Tener todo tu código usando ese setter en lugar de simplemente establecer valores directamente significa que el error se detecta en el momento en que se realiza y no mucho después cuando se usa ese valor. Un caso similar para un getter es cuando hay un valor predeterminado lógico, que se debe usar en caso de nulo. Al usar un captador, puede escribir de forma segura métodos locales sin necesidad de verificaciones nulas continuas o opciones predeterminadas.

Dicho esto, si no hay lógica de negocios en esos métodos, y no hay efectos secundarios causados ​​por ellos, entonces es principalmente una cuestión de estilo. Esencialmente, la clase tiene la responsabilidad de ser internamente coherente, y mientras siga siendo así, es sobre todo preferencia personal/profesional si accede a las variables directamente oa través de métodos de ajuste.

Answer 5

Algunos de nosotros somos desarrolladores web, por lo tanto, recurrimos a la creación de JavaBeans y JavaBeans tiene su propia specification. En la especificación, establece claramente:

• La clase debe tener un constructor predeterminado público (sin argumento).
• las propiedades de clase deben ser accesible usando obtener, conjunto, es (utilizados para propiedades booleanas en lugar de GET) y otros métodos.
• La clase debe ser serializable.

La razón de ser, JavaBeans fue diseñada para Reutilización donde JavaBeans pueden viajar a través de las tecnologías Java (por ejemplo, servlets, JSP, RMI, servicios web, etc.).

Ese es mi valor de 2 céntimos en por qué tenemos getters/setters. Yo principalmente creo JavaBeans.

Answer 6

Algunas personas piensan que siempre deben encapsular todos los campos utilizando setters/getters. Otros piensan que esta práctica no debe usarse en absoluto.

Si su clase no tiene ninguna lógica para los campos y solo se utiliza como titular, puede omitir el uso de métodos y declarar sus campos como públicos. Este concepto también se llama un objeto de transferencia de datos (o mensajero.) Pero, como regla general, debe utilizar el atributo final para estos campos para que su clase inmutable:

public class TwoTuple<A,B> { 
    public final A first; 
    public final B second; 
    public TwoTuple(A a, B b) { first = a; second = b; } 
} 

Sin embargo, usted debe/o se recomienda encarecidamente el uso de fijadores/getters:

• en aplicaciones web a veces hay requisitos para usar setters/getters. Ver objetos POJO/JavaBean.
• si su clase se va a utilizar en un entorno concurrente. Consulte Java Concurrency in Practice, Sección 3.2: "Si otro hilo realmente hace algo con una referencia publicada realmente no importa, porque el riesgo de mal uso aún está presente. [7] Una vez que un objeto se escapa, debe suponer que otro la clase o el subproceso pueden, maliciosamente o descuidadamente, hacer un mal uso. Esta es una razón convincente para usar la encapsulación: hace que sea práctico analizar programas para corregir y dificultar más las restricciones de diseño accidentalmente "
• si desea agregar algo de lógica extra cuando usted establece/obtiene valores, debe usar setters/getters. Acabo de leer sobre la encapsulación y sus ventajas.

Mi opinión siempre declara los campos como "final privado" y solo entonces, si es necesario, cambie estas propiedades.