¿Es una buena práctica usar siempre métodos de acceso, incluso cuando se accede al estado local?

Question

Considere la clase siguiente:

public class Person 
{ 
private Integer age; 

// Standard Accessors 
public Integer getAge() { 
    return age; 
} 

public void setAge(Integer age) { 
    this.age = age; 
} 

public String getAgeAsTextString() 
{ 
    if (this.age == 20) 
    { 
     return "Twenty"; 
    } 
    return "Unknown"; 
} 
} 

sólo tengo 1 Entero y 2 descriptores de acceso. Si deseo crear un método de utilidad que devuelva el estado de los objetos como una cadena, ¿es una mejor práctica referirse a la variable de clase como this.age, o debería estar usando getAge()?

¿Existe una mejor práctica o se debe a la discresión del desarrollador?

Answer 1

Depende. Para clases rápidas pequeñas en las que los usuarios no hacen nada, yo diría que usan los campos directamente. Para las clases más grandes donde los accesorios y el colocador podrían tener efectos secundarios, yo diría que usan accesadores.

En la plataforma Android, la documentación de Android parece estar de acuerdo. Incluso llegan a recomendar la protección del nivel de paquete en ciertos casos. Consulte las secciones tituladas "Evitar compiladores/ajustadores internos" y "Usar el alcance del paquete con clases internas" en http://developer.android.com/guide/practices/design/performance.html.

Todo depende del entorno, el tamaño del código y si hay "normas" acordadas para el mantenimiento del código.Solo sé que hay una pequeña diferencia en el rendimiento, pero al final depende del desarrollador/equipo.

Answer 2

Es una buena práctica porque nunca puede estar seguro de cómo le gustaría cambiar la edad en una fecha posterior. Puede necesitar algún tipo de validación u otra cosa y es más fácil cambiarla en un método que en cualquier lugar en el que se use el campo (y es mucho más fácil pasar por alto un lugar donde se usa y, por lo tanto, tiene alguna dificultad para localizar un posible error)

Answer 3

Yo diría que se reduce a la discreción del desarrollador.

I ligeramente prefieren usar el método getter. Y si tiene una jerarquía de clases, es bueno exponer el estado interno a través de getters protegidos.

Answer 4

A menudo las personas van con this.age en una clase simple, pero consideren los beneficios de usar accesos cuando ya los tienen. Si desea presentar un día, por ejemplo, iniciar sesión cuando alguien tenga la edad, tendrá que ponerlo en cada lugar que llame this.age. O, en su lugar, puedes ponerlo en el accesorio. El estilo del código no siempre es fijo, pero generalmente hay una buena razón si lo buscas.

Answer 5

En mi humilde opinión: sigo el principio de You-Aint-Gonna-Need-It de mantener las cosas simples. A muchos desarrolladores les preocupa que algún día, es posible que necesites un getter o setter, cuando en realidad esto nunca sucede.

Debe hacer lo que cree que es más claro, especialmente para aquellos que tienen que mantener su código.

Sugeriría que es una buena práctica usar int, a menos que necesite que el valor sea nulo o un objeto. Si necesita que el valor sea potencialmente nulo, debe probarlo.

es decir, ya sea

int age = 10; 
if (this.age == 20) // cannot be null. 

O

Integer age = 10; 
if (this.age != null && this.age == 20) // age can be null 

Nota

Integer age; 
if (this.age == 20) // throws an NPE. 

Answer 6

Si la clase sería definitiva, me gustaría acceder a los campos directamente. Confíe en sus capacidades de refactorización. Si quieres cambiarlo más tarde, siempre puedes hacerlo.

Answer 7

Me gusta usar getters y setters incluso para clases simples porque crea "Hooks" en tu código, lo que facilita la extensión. Por lo tanto, si desea crear una entrada de auditoría cada vez que un usuario cambia una determinada propiedad del objeto, es fácil de hacer. Luego, cuando llegue al final de mi proyecto, me tomaré un momento y eliminaré los getters y setters que no use. Encuentro esto efectivo porque la mayoría de los IDE generarán los accesadores para que no se desperdicie mucho tiempo ...

Veo gente publicando, "Si quiere cambiarlo más adelante, siempre puede hacerlo".. Esto no siempre es trivial en proyectos grandes, cuando accede directamente a las propiedades de su objeto en todo su código.

Answer 8

Por el amor de Dios, no juegues tu código con la "auto encapsulación" oximorónica. La clase es tu módulo. Haz que tu clase sea simple.

Además, diseñe la interfaz de su clase en términos de comportamiento en lugar de datos. Deshazte de esos y establece los métodos.

Answer 9

Una cosa para recordar. Cuando se utiliza algo como Hibernate, el uso de los accesorios generalmente es requerido! Han sido mordidos por este unas cuantas veces. Hibernate usa la generación de código de bytes para hacer una inicialización lenta. si accede directamente a la variable miembro, omitirá la carga diferida y obtendrá valores nulos. Entonces, mi mejor práctica personal es usar el accesorio. Como todas las mejores prácticas, por supuesto, hay veces para ignorarlo, pero ahí lo tienes.

Answer 10

Mientras que los accesos para agregar líneas de código a sus clases, realmente agregan valor al refactorizar el código. ¿Necesitas notificar a otra clase que una propiedad ha cambiado? BAM! hay un evento y lo activa dentro del código de acceso.

Con solo hacer que la variable miembro sea accesible, debe crear el acceso cuando necesita crear el evento o recordar agregar la lógica para notificar el objeto cada vez que un objeto fuera de su clase cambia la variable miembro .

Creo que los accesadores son excelentes por su flexibilidad a las proporciones de complejidad. Además, algunos frameworks, como hibernate, los requieren. Además, los lenguajes como .net tienen estructuras de código como atributos que no se pueden aplicar a variables miembro (también conocido como WCF DataMember).

Espero que ayude!

Answer 11

Algunas razones por las descriptores de acceso "puede" ser una mejor opción:

1. Está utilizando un marco de burla para probar el código y desea tener la capacidad para cambiar el valor de regresar de un captador, y hacer valer que fue llamado.
2. Quiere exponer la mayoría (si no todas) de sus clases públicas como interfaces (por ejemplo, desea poder crear proxies dinámicos, etc.). Esto puede incluir la exposición de accesadores en la interfaz (la persona que llama no necesita saber que está recuperando una propiedad local)
3. Está desarrollando una biblioteca para el consumo público, y un "refactorio simple" no es apropiado, ya que puede () causar errores de tiempo de compilación en la aplicación del usuario final. Los usuarios pueden dejar de usar apropiadamente sin afectar el comportamiento de los usuarios de la biblioteca anterior.
4. Desea reservar el derecho de cambiar el comportamiento del descriptor de acceso en un momento posterior, o en una clase derivada sin eliminarlo por completo (consulte el punto anterior).
5. Muchos frameworks de inyección de dependencias esperan que un "bean" se ajuste a las especificaciones de JavaBeans y, por lo tanto, tienen acceso para todas las propiedades.