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?

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.

No necesitamos arquitectos. Claro que NO. Somos un equipo de desarrolladores competentes, todos muy capaces, genios comprobados y mal apreciados, somos la crema y nata de la tecnología, los ases de la codificación, los reyes de los lenguajes y las tecnologías. NO. Nosotros no necesitamos ningún dinosaurio con pretensiones de Anciano de la Matrix que venga a decirnos lo que Nosotros, amos y señores, ya sabemos. Los arquitectos son para equipos de retardado y cuasi idiotas. Y…. este, mis queridos lectores, es el modo de pensar de muchos equipos de desarrollo en la actualidad. Como dijo un querido amigo, llenos de concreciones y nada de abstracciones. Pero, adentrándonos en el tema, primero necesitamos resolver algo, ¿cual es el rol del arquitecto de software en un equipo de desarrollo? Muchos piensan que el arquitecto es el responsable de definir los componentes estructurales y comunicacionales de un proyecto de software. Y eso es verdad. Pero es baladí por ser ...

Hace un buen rato, en la época que el Lotus 123 dominaba en las hojas de cálculo, que leí un excelente artículo que se denominaba: Programación Orientada a Objetos con Lenguaje C. Si, no hay error. No falta un ++ allí. Es POO con el maravilloso lenguaje C. El artículo en cuestión, proponía como utilizar las estructuras de datos y punteros de C para emular el comportamiento de Clases y Objetos. Hacía énfasis en diversas técnicas para aprovechar el encapsulamiento, la herencia y otros principios y conceptos de la POO con el C. Acá un enlace a una publicación que menciona algunas de estas técnicas.

Recientemente me encontraba trabajando con uno de estos programadores que creen que programar es “echar” líneas de código, y que piensan que conocer un lenguaje de programación los hace programadores como tal. Este individuo en cuestión, incluso parloteaba sobre Patrones de Diseño, más específicamente sobre el patrón de diseño Factory . Cuestionaba este sujeto el uso del patrón Factory a lo largo de un  código. Él no estaba de acuerdo, y decía que uno usa el Factory es “cuando no sabe que clase va a instanciar”, que si sabemos cuál es la clase no debemos usar Factory porque es más lento que la instanciación directa del objeto y además introducimos mucha “indirección”, esa es la palabra que usó,  en el código. Esto sólo demuestra un par de cosas. La primera es que tenemos a alguien que cree que conoce algo. La segunda es que lo conoce MAL. En primer lugar el patrón Factory no se usa porque sepamos o no que clase debemos instanciar. Se usa porque garantiza q...