HAL 9K

Es mucho el artículo, publicación y blogs de , ¿supuestos?, entendidos en el tema que hablan sobre, o exponen el problema con, el uso o más bien ABUSO de los Getters y Setters en la programación orientada a objetos (OOP). Es este un tema recurrente y para nada nuevo, no señor, de hecho viene dando vueltas en el entorno de desarrollos OOP desde hace un buen rato. Pero.... ¿Cuál es el gran problema con usar getters y setters?

No, este no es un artículo sobre política, sigue siendo sobre programación orientada a objectos (OOP), específicamente sobre métodos públicos y propiedades privadas , de allí el título. Todo surge por un comentario que me hizo un querido amigo al leer mi publicación sobre l as reglas pigbar de programación . El me comentó: "Mr. Bladi, entiendo sus reglas acerca de que las propiedades deban ser privadas por aquello del encapsulamiento, ¿pero que todos los métodos deban ser públicos? eso me cuesta entenderlo, eso implica que no existen métodos privados, y yo debo saber lo que un objeto hace sin preocuparme del cómo, por lo que esos métodos privados pueden ser útiles."

Uno de los grandes errores de la programación orientada a objetos ( OOP ) con Java ha sido la existencia de las referencias a NULL . Esta es la causa del popular y formidable error “ java.lang .NullpointerException ”. Toda una embrarrada. La existencia de este tipo de referencia es la causa de muchos dolores de cabeza, de muchísimo código innecesario y defensivo, de muchas malas prácticas y de una pésima filosofía de desarrollo.

Y luego de un largo rato volvemos por acá con una historia basada en hechos reales, sobre una conversación muy didáctica que tuve con un amigo: -Mr. Bladi, he escuchado que Ud. se opone, es más desprecia, al uso de las clases Utilitarias y los métodos estáticos en la programación orientada a objetos (OOP). -Ciertamente. No aconsejo su uso y lo considero una mala práctica, algo ofensivo en la OOP. -Pero si no podemos usar clases utilitarias y métodos estáticos, ¿Cuáles opciones Tenemos? -Tenemos unas cuantas opciones. Pero antes un poco de contexto. Las clases utilitarias, esas que están repletas de métodos estáticos, no son objetos reales, son un recurso totalmente procedimental y rompen el principio de encapsulamiento en la OOP. Peor aún, las clases utilitarias con su torrente de métodos estáticos, son muy difíciles de testear en las pruebas automáticas.  TODO MÉTODO ESTÁTICO, E INCLUSO LOS PRIVADOS, SON CANDIDATOS PARA UNA NUEVA CLASE, es decir son elegibles ...