Entidad objetos getters y setters para propiedades de datos

Question

Hace poco empecé a trabajar en Java y me introdujeron en el mundo salvaje y loco de los que consiguen y configuran todo. Lo odié al principio, pero rápidamente me acostumbré. Demasiado acostumbrado a ello.

Últimamente he pasado mucho tiempo pensando más en el diseño de clase. Una de las cosas que estoy tratando de hacer es evitar la trampa de hacer captadores y definidores para todo. Sin embargo, gran parte del trabajo que hago es con entidades que son principalmente contenedores de datos y no estoy seguro de que los captadores y definidores sean realmente inadecuados en estos casos.

Aquí hay un ejemplo simple que usa propiedades públicas.

class Space {
    public String name;
    public String description;
    Space(final String name, final String description) {
        this.name = name;
        this.description = description;
    }
}

Aquí hay un ejemplo simple que usa propiedades privadas y que usa captadores y definidores.

class Space {
    private String name;
    private String description;
    Space(final String name, final String description) {
        this.name = name;
        this.description = description;
    }
    public String getName() {
        return this.name;
    }
    public void setName(final String name) {
        this.name = name;
    }
    public String getDescription() {
        return this.description;
    }
    public void setDescription(final String description) {
        this.description = description;
    }
}

En estos ejemplos, los campos name y description deberían poder cambiarse.

Siento que el ejemplo de getter / setter es más claro y oculta los detalles de implementación de lo que son name y description . También permitiría la validación en el conjunto más tarde si fuera necesario.

He leído varias discusiones acerca de que los captadores y seteadores son malvados y / o antipatrónicos, pero realmente siento que es posible que no se apliquen a esta situación.

Tal vez hay algunas opciones que aún no he considerado. Estoy abierto a sugerencias!

Answer 1

Para ponerlo simple:

• Necesita captadores para todos los campos que deben leerse desde afuera.
• Necesita definidores para todos los campos que deben escribirse desde el exterior.

Esto puede ser del 100%, pero la mayoría de las veces es menos.

Answer 2

La primera versión (propiedades públicas) no es una buena idea. El segundo es mejor. Como diría Josh Bloch, " favorece la inmutabilidad " :

public class Space {
    private final String name;
    private final String description;

    public Space(final String name, final String description) {
        this.name = name;
        this.description = description;
    }

    public String getName() {
        return name;
    }

    public String getDescription() {
        return description;
    }
}

Dicho esto, los recolectores y los instaladores tienden a ser abusado .

Answer 3

Has escuchado que el " get / setters are evil de a menudo excesivamente simplificado " ;. Nadie (espero) realmente significa que hay algo malo en ello para los objetos de datos. Creo que la verdadera idea es:

" Getters / Setters son malos, excepto para los objetos de almacenamiento de datos simples " que en sí mismo es solo un evangelismo de "decir, no preguntar".

Idealmente, si una clase tiene captadores y definidores, eso es todos que debería tener.

Ese es el argumento de todos modos. No estoy seguro de estar de acuerdo con ello.

Answer 4

Si bien el patrón de accesores ayuda a ocultar los detalles de implementación de una clase (por ejemplo, usar una tabla hash para almacenar atributos para ahorrar memoria en clases poco utilizadas), puede ser muy detallado de implementar (su ejemplo tiene 12 líneas más con accesores). Es por eso que C # tiene una sintaxis de propiedad especial, que permite especificar de manera concisa los accesores predeterminados:

class Space {
    public String Name { get; set; }
    public String Description { get; set; }
    Space(final String name, final String description) {
        this.Name = name;
        this.Description = description;
    }
}

Los formularios alternativos pueden agregar especificadores de acceso y / o código:

private String _name;
public String Name {
    get { if (_name == null) FetchName(); return _name; }
    private set { _name = value; }
}