ErradicadorDeMétodosGet
Escrito por Martin Fowler
Traducido por Jorge Ferrer
Puedes reconocerlos por el tick en el lado izquierdo de la boca cada vez que ven un método get (getter). Se produce un movimiento rápido de su hacha de guerra y se oye un grito de satisfacción cuando un getter es eliminado sin piedad de una clase que inmediatamente se desvanece en un éxtasis de agradecimiento a los pies de erradicador de métodos get.
Está bien, quizá el volver a la cerveza inglesa me está afectando demasiado, pero el “pellizco cariñoso” de Chris despertó una cruzada personal mía. A menudo me he encontrado con gente que recomienda evitar métodos get en las clases, considerándolos una violación de la encapsulación. El artículo de Allen Holub es uno de los más conocidos.
La justificación general es que los métodos get violan la encapsulación. Si tengo una clase Bowler (Bateador en criquet) con campos para Overs, Runs y Wickets, entonces añadir métodos get (getOvers, getRuns, getWickets) es mejor que hacer los campos públicos.
El argumento tiene cierto sentido y de hecho yo recomiendo que no se escriban métodos de acceso a campos (accessors) hasta que son realmente necesarios, pero también conlleva el peligro de malinterpretar el objetivo de la encapsulación. Para mí su objetivo no es realmente esconder los datos, sino esconder las decisiones de diseño, en particular en aquellas areas donde esas decisiones pueden tener que cambiar. La representación interna de datos es un ejemplo de esto, pero no es el único y ni siquiera es siempre el mejor. El protocolo usado para comunicarse con un almacen de datos externo es un buen ejemplo de encapsulación – uno que trata más sobre los mensajes intercambiados con el almacen que sobree la representación de ningún tipo de datos. Cuando se piensa sobre encapsulación yo creo que es mejor preguntarse “¿qué variabilidad estás ocultando y por qué?” en lugar de “Estoy exponiendo datos”. (Craig Larman escribió una buena columna para mí sobre este tema)
Aunque la defensa de la encapsulación es una reivindicación común para los erradicadores de métodos get, creo que su verdadera motivación es algo más razonable y pragmática. Hay una barbaridad de código en lenguajes orientados a objetos cuyo diseño es procedimental. Quizá la comunidad de la orientación a objetos pueda haber 'ganado' en el sentido de que los lenguajes modernos están dominados por objetos, pero aún deben ganar en el sentido de que la programación orientada a objetos no está siendo usada ampliamente todavía. Como consecuencia de esto aún es común ver procedimientos que recuperan datos de un objeto para hacer algo con ellos cuando ese comportamiento encajaría mejor en el propio objeto – una violación de lo que los 'pragmatic programmers' [NT: Martin fowler se refiere a Andy Thomas y Dave Hunt autores del libro “The Pragmatic Programmer”, “El programador pragmático" identifican como el principio “Dí, no consultes” (Tell Don't Ask). Sólo puede hacerse este tipo de programación procedimental usando métodos get, así que decirle a la gente que no los use ayuda a guiarlos a mover el comportamiento al lugar correcto.
Tengo una gran simpatía con esta motivación, pero me temo que simplemente decir a la gente que evite los métodos get es un arma sin filo. Demasiado a menudo hay objetos que necesitan colaborar intercambiado datos lo que conlleva la necesidad auténtica de un método get.
Si se está buscando una regla general, mi preferida es una que escuché por primera vez a Kent Beck y que consiste en estar alerta en los casos en los que cierto fragmento de código invoca a más de un método del mismo objeto. Esto ocurre con métodos de acceso y otras operaciones. Si pides a un objeto dos fragmentos de datos, ¿puedes remplazar esas peticiones con una única para obtener directamente el fragmento de datos que estás calculando? Si le pides a un objeto que haga dos cosas, ¿puedes reemplazarlo con una única operación? Por supuesto hay numerosos casos en los que no se puede, pero siempre merece la pena hacerse la pregunta.
Otro signo de alerta son las clases de datos (Data Class) – una clase que únicamente tiene campos y métodos de acceso a ellos. Casi siempre esto es una señal de problema porque hay una carencia de comportamiento. Si se encuentra una de ellas siempre se debe sospechar. Busca quién está usando los datos y prueba a ver si es posible mover parte del comportamiento dentro de la clase. En estos casos puede ser útil preguntarse “¿puedo deshacerme de este método get?”. Incluso aunque no se pueda, hacerse la pregunta puede provocar movimientos positivos del código con el comportamiento.
La correcta colocación del comportamiento entre los objetos es la esencia del diseño orientado a objetos, aunque como con cualquier diseño, no hay ninguna regla rápida y general – sino una necesidad de evaluar las alternativas y llegar a un compromiso. Situar el comportamiento en la misma clase que los datos, lo que Craig Larman denomina el “Experto en información” (Information Expert) es la primera opción a considerar. Pero no es el único camino. La organización en capas a menudo es preferible, muchos de los patrones del Gang of Four separan los datos del comportamiento para necesidades particulares. Una buena regla general es que las cosas que cambien juntas deben estar juntas. Los datos y el comportamiento que usa esos datos a menudo cambiarán juntos, pero también es habitual encontrarse con otras agrupaciones que resultan más importantes.
