[<https://martinfowler.com/bliki/GetterEradicator.html>](<https://martinfowler.com/bliki/GetterEradicator.html>)
La justificación general es que los getters violan la encapsulación. Si tengo una clase de jugador de bolos con campos para overs, carreras y wickets, entonces añadir getters (getOvers, getRuns, getWickets) es poco mejor que simplemente hacer los campos públicos.
Este argumento tiene algo de sentido, y ciertamente sugiero que no se escriban getters hasta que realmente se necesiten, pero también conlleva el peligro de perder el objetivo de la encapsulación. Para mí, el punto de la encapsulación no es realmente ocultar los datos, sino ocultar las decisiones de diseño, particularmente en áreas donde esas decisiones pueden tener que cambiar. La representación interna de los datos es un ejemplo de ello, pero no el único y no siempre el mejor.
Cuando se piensa en la encapsulación, creo que es mejor preguntarse "qué parte de la variabilidad está ocultando y por qué" en lugar de "estoy exponiendo datos". (Craig Larman escribió una buena columna sobre esto).
Aunque la defensa de la encapsulación es el grito de guerra común para los erradicadores de getters, creo que la verdadera motivación para ellos es bastante más razonable y pragmática. Hay una gran cantidad de código en los lenguajes OO que tiene un diseño procedimental. Puede que la comunidad OO haya "ganado" en el sentido de que los lenguajes modernos están dominados por los objetos, pero todavía no han ganado en el sentido de que la programación OO todavía no se utiliza ampliamente. Como resultado, todavía es común ver procedimientos que sacan datos de un objeto para hacer algo, cuando ese comportamiento encajaría mejor en el propio objeto - una violación del principio de los programadores pragmáticos de "Decir no preguntar". Sólo puedes hacer este tipo de programación procedimental si tienes getters, así que decirle a la gente que se deshaga de los getters ayuda a empujarlos a mover el comportamiento al lugar correcto.
pero me temo que decirle a la gente que evite los getters es una herramienta bastante contundente. Hay demasiadas veces en las que los objetos sí necesitan colaborar intercambiando datos, lo que lleva a necesidades genuinas de getters.
Una clase que sólo tiene campos y accesores. Eso es casi siempre una señal de problemas porque carece de comportamiento. Si ves uno de esos siempre debes sospechar. Busque quién utiliza los datos y trate de ver si algo de este comportamiento puede ser trasladado al objeto. En estos casos puede ser útil preguntarse "¿puedo deshacerme de este getter?". Incluso si no puedes, hacer la pregunta puede conducir a algunos buenos movimientos de comportamiento.
La asignación del comportamiento entre los objetos es la esencia del diseño orientado a objetos, así que, como en cualquier diseño, no hay una regla dura y rápida - más bien un juicio de compensaciones. Poner el comportamiento en la misma clase que los datos, lo que Craig Larman llama "Experto en Información", es la primera opción a considerar. Pero no es la única vía. La estratificación a menudo supera esto, muchos de los patrones de la Banda de los Cuatro separan los datos del comportamiento para necesidades particulares. Una buena regla general es que las cosas que cambian juntas deben estar juntas.