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 ...

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.

Cuando la programación estructurada era la que mandaba en el mundo, y submundos, del desarrollo de software, muchos fuimos los evangelizadores, cuando no creyentes, que proponíamos esta forma de programación y, aún más relevante, sus metodologías asociadas RUP, Waterfall, Etc., como la panacea, la crema y nata, de la construcción de soluciones de software. Pasamos lustros, décadas, en esas lides. Y nos fue bastante bien. Luego vino la programación orientada a objeto (OOP), con sus alternativas metodológicas asociadas, y lo cambió todo nuevamente. Y, como era de esperarse, no faltábamos los nuevos conversos, los profetas de la OOP y de sus métodos, filosofías y procesos. No a pocos, lo que no sonara a OOP les hacía fruncir el ceño, casi les producía arcadas pues!! Vale decir que con la OOP también nos ha ido bastante bien como vendedores de “vaporware” (luego explico el término) que somos jajajajaja…. Y así por el estilo. Programación funcional, Cloud, Quantum… es l...

SOLID es un acrónimo para una serie de principios básicos, 5 en total,  de la programación orientada a objetos ( POO ) y el diseño orientado a objetos ( OOD ) inventado por Robert C. Martin. Estos principios tienen relación con algunos patrones de diseño. Muchos creen que el objetivo de la arquitectura de software, los patrones de diseño y los principios SOLID es programar más rápido. Pero no. La verdad es que el objetivo real es facilitar el mantenimiento de los grandes proyectos de software. Como norma el mantenimiento consume muchos recursos de los destinados a los proyectos de software, hasta un promedio de 77%, por lo que los ahorros en esfuerzos en esta área son cruciales para facilitar el sostenimiento de una plataforma de software o de soluciones de software cualquiera. En forma general estos principios son los que a continuación se detallan…

Era popular entre mis amigos de carrera la expresión “Para qué lo vamos a hacer fácil si lo podemos hacer difícil”, y es esta expresión la que resume el primero de los extremos de los que hablaré en esta publicación. Me refiero al Sobre diseño. Entendiendo como tal la consideración e implementación de estructuras de software con características de funcionalidad, configuración, mantenimiento y usabilidad innecesarias, o totalmente prescindibles, para alcanzar un objetivo o resolver un problema. Imagine que Ud. se encuentra almorzando plácidamente, cuando de pronto es importunado por el zumbido y presencia de una asquerosa mosca volando cerca de su plato de comida. Visiblemente molesto, se dispone a resolver el problema y dar cacería al desagradable intruso. Para ello contrata a tres consultores, con miras a que le propongan la mejor alternativa para resolver su problemática con la plaga voladora. El primer consultor le recomienda usar simplemente sus manos y perseguir y ap...

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...

Parte de las tareas comunes que enfrentamos cuando trabajamos con el Oracle UCM por medio de la api RIDC , es la de validar los permisos de acceso de un usuario sobre un archivo cualquiera dado su Id de documento. Para ello nos valemos de una implementación de la interface IUserSecurityCache, y usamos el método getAccessLevelForDocument(...). Dejo a continuación un fragmento de código de ejemplo: public class RIDCBusiness { public static int getAccesLevelForDocumentByIdAndUser( String idConnectionURL, String usernameForConnect, String userNameToCheck, String documentId) { int levelAccess = -1; try { final IdcClient mclient = getUCMConnection(idConnectionURL, usernameForConnect); // RIDC superuser context // use las credenciales adecuadas a su plataforma final IdcContext msuperuser = new IdcContext("weblogic", "weblogic"); final IUserSecurityCache mSGAcctAclCache = new UserSGAcctAclCache(mclient, 20, 1000, 20000, ms...

En un reciente proyecto me vi en la necesidad de trabajar con el Oracle Universal Content Manager (UCM) mediante a API de RIDC. Abundan en la web ejemplos de como hacer esto, lo cual fue una gran ventaja para mis tareas. No obstante, fue más difícil encontrar en buen ejemplo para acceder a los FOLIOS del UCM, e incluso me encontré con algunos problemas a la hora de pasar los parámetros en forma adecuada. Es por ello que hoy dejo un breve fragmento de código que muestra como acceder a los servicios de RIDC mediante Java. Para ello creé un proyecto Java en eclipse, y agregué las librerías oracle.ucm.ridc-11.1.1.jar y oracle.ucm.ridc.was-lib-11.1.1.jar . Use un Pojo,  ConsultaDocumentos , para modelar los documentos. Este Pojo puede ser usado en un contenedor de Vaadin u otro framework para representar los resultados de los documentos contenidos en un FOLIO de Oracle UCM.

Ejemplo: Imagine el escenario donde Ud. llega a un local de comida rápida, seguramente ha hecho esto alguna vez en su vida, lo primero que hace es ir y decirle al cocinero, en voz alta por supuesto: “oye tu, quiero una hamburguesa doble carne bien cocida”, seguidamente le dice al muchacho de los refrescos: “me preparas una gaseosa enorme” y por último le dice al de las ensaladas: “¡me pones de todo con un poco de todo encima!”. ¿No es así como se acostumbra?  Parece que no.  Bien hagamos algunas correcciones. Ud. llega al local y lo recibe un cajero; nada de estar pegando gritos al cocinero y al resto del personal, seguidamente el cajero toma su pedido y él si procede a decirle al cocinero lo que Ud. quiere, le grita al de los refrescos su orden, y claro está, habla con el de las ensaladas para que le ponga de todo.