¿Qué es más apropiado: getters y setters o funciones?

Question

¿Es apropiado abandonar el " getMyValue () " y " setMyValue () " patrón de captadores y definidores si los nombres de funciones alternativas hacen que la API sea más obvia?

Por ejemplo, imagina que tengo esta clase en C ++:

public class SomeClass {
private:
    bool mIsVisible;

public:
    void draw();
    void erase();
}

Podría agregar funciones para obtener / configurar " mIsVisible " de esta manera:

bool getVisible() { return mIsVisible; };


void setVisible(bool visible) { 
    if (!mIsVisible && visible) {
        draw();
    } else if (mIsVisible && !visible) {
        erase();
    }

mIsVisible = visible;


}

Sin embargo, sería igualmente posible utilizar los siguientes métodos en su lugar:

bool isVisible() { return mIsVisible; };

void show() { 
    if (!mIsVisible) {
        mIsVisible = true;
        draw();
    }
}

void hide() {
    if (mIsVisible) {
        mIsVisible = false;
        erase();
    }
}

En resumen, ¿es mejor tener un solo " setVisible (bool) " método, o un par de " show () " y " ocultar () " métodos? ¿Existe una convención, o es puramente algo subjetivo?

Answer 1

Lea el artículo " Diga, no pregunte " En el sitio web de Pragmatic Programmers, creo que verás que el segundo ejemplo es el camino a seguir.

Básicamente, no debes distribuir la lógica a través de tu código, lo cual está implícito en tu primer ejemplo, a saber:

1. obtener valor de visibilidad actual,
2. tomar una decisión basada en el valor,
3. actualizar objeto.

Answer 2

En el ejemplo que dio, show () y hide () tiene mucho sentido, al menos para mí.

Por otra parte, si tenía una propiedad skinPigment y decidió realizar las funciones llamadas tanMe () y makeAlbino () que Sería una opción realmente pobre, no obvia.

Es subjetivo, debes tratar de pensar de la manera en que piensan los usuarios (las personas que utilizan esta clase). De cualquier forma que decida, debe ser obvio para ellos, y well-documented.

Answer 3

Iría con el conjunto isVisible () / show () / hide ().

setVisible () implica que todo lo que hace cambia la variable interna. Mostrar () y ocultar () aclaran los efectos secundarios.

Por otra parte, si todo getVisible () / setVisible () hizo fue para cambiar la variable interna, entonces solo has cambiado muy poco de tenerlos como campos públicos.

Answer 4

Los configuradores

en realidad tienen muy poco que ver con la orientación a objetos, que es el lenguaje de programación aplicado en el ejemplo. Los captadores son ligeramente mejores, pero en muchos casos se pueden vivir sin ellos. Si todo se puede obtener y configurar, ¿para qué tener un objeto? Se debe llamar a las operaciones sobre los objetos para lograr cosas, cambiar el estado interno no es más que un efecto secundario de esto. Lo malo de un colocador en presencia de polimorfismo, una de las piedras angulares de OO, es que obligas a cada clase derivada a tener un establecedor. ¿Qué sucede si el objeto en cuestión no necesita un estado interno llamado mIsVisible? Claro que puede ignorar la llamada e implementarla como vacía, pero luego te quedas con una operación sin sentido. OTOH, operaciones como mostrar y ocultar se pueden anular fácilmente con diferentes implementaciones, sin revelar nada sobre el estado interno.

Answer 5

En general, creo que los setters / getters solo deben establecer los valores de las propiedades. En su ejemplo, también está realizando una acción basada en el valor de la propiedad isVisible. En este caso, argumentaría que usar funciones para realizar la acción y actualizar el estado es mejor que tener un setter / getter que realice una acción como un efecto secundario de actualizar la propiedad.

Answer 6

Si el cambio de mIsVisible realmente activa y desactiva la visibilidad del objeto inmediatamente, entonces use el escenario mostrar / ocultar. Si se mantendrá en el estado anterior un poco más de tiempo (por ejemplo, hasta que otra cosa desencadene un redibujado), el escenario establecer / obtener sería el camino a seguir.

Answer 7

Prefiero los métodos show () y hide () porque te dicen explícitamente lo que estás haciendo. El setVisible (booleano) no le dice si el método se va a mostrar / dibujar de inmediato. Además, show () y hide () son métodos con mejor nombre para una interfaz (IMHO).

Answer 8

Implícitamente, las funciones 'mostrar' y 'ocultar' que enumeras son ambas definidoras

Para los booleanos, creo que una sola herramienta como la que has mostrado sería buena. Sin embargo, las funciones .show y .hide también se parecen a los comandos, no a las funciones que cambian el estado del objeto.

Answer 9

En el caso de que realmente tengas que escribir código como

if (shouldBeShowingAccordingToBusinessLogic()) w.show();
else w.hide();

por todas partes, puede que estés mejor con

w.showIfAndOnlyIf(shouldBeShowingAccordingToBusinessLogic())

O, para casos realmente extraños, cuando tu lógica no puede decidir si hacer dhow o no hasta el final de algún estiramiento de código, puedes intentarlo

w.setPostponedVisibility(shouldBeShowingAccordingToBusinessLogic());
...
w.realizeVisibility();

(¿No dije que es bizzare?)

Answer 10

Una motivación adicional para buscar la solución de visualización / ocultación es que, como configurador,

el método setVisible tiene un 'efecto secundario', ya que también muestra u oculta SomeClass . Los métodos de mostrar / ocultar transmiten mejor la intención de lo que sucede.