Paso V: ¿Conoce usted qué significa desarrollar con Objetos?

Antes de proseguir, quiero dejar claro que en este paradigma si un objeto no tiene cierta responsabilidad es porque la tiene otro, no existe alternativa. Por lo tanto, si le saco la responsabilidad a las llamadas de calcular su costo, se la tengo que dar a otro objeto, no hay alternativa. La pregunta en cuestión es ¿cuál es ese objeto? Nuevamente debemos recurrir a una analogía. Pensemos por un momento como sería una oficina encargada de facturar llamadas telefónicas, que no posea ningún tipo de computadora para automatizar el procedimiento. ¿Qué personas compondrían esta oficina?, ¿cuáles serían sus responsabilidades? Seguramente habría una persona encargada tipificar una llamada para luego determinar su costo en base a una tabla de precios. Estos son los objetos que necesitamos en nuestro modelo, uno para representar a la persona que tipifica y factura (¿o quizá dos?) y otro para representar la tabla de precios.

El primero puede ser instancia de la clase “Facturador”, sabrá responder cuál es el costo de una llamada dada una tabla de precios. La tabla de precios será otro objeto que indicará el costo por pulso de cada tipo de llamada. Juntos, nos permitirán obtener el costo de una llamada y por lo tanto de todas.

Unos párrafos atrás comenté que la solución no estaba “a la vista”. Esto se debe a que los objetos que necesitábamos ni siquiera estaban mencionados en el enunciado del problema; encontrarlos requiere cierto poder de análisis, capacidad de abstracción para crear analogías y porque no, un pizca de imaginación (¿será por esto que algunos ver la programación como un arte?). Lo interesante de este caso es que ustedes pueden, a partir de ahora, hacer analogías similares para resolver los problemas que se les presentan, utilizar la misma técnica y ver que resultados obtienen. Les aseguro que serán muy positivos.

Sin embargo suena un poco raro que un facturador solo responda el costo de una llamada, su nombre parece indicar otra cosa. En realidad lo que estoy esperando de dicha persona (objeto) es una factura para un cliente. Nuevamente nos encontramos con un caso interesante de este problema, empezamos a hablar de factura algo que no había surgido hasta ahora pero que se comenta en el enunciado. Recuerden la máxima de este paradigma: “Todo ente de la realidad que se está modelando debe tener un objeto que lo represente”; por lo tanto si existe una factura en la realidad, una factura debemos tener en nuestro modelo, o sea, en nuestro programa. ¿Se les había ocurrido tener un objeto para representar la factura? De todas las entrevistas que tomé con este problema, nadie, pero nadie modelo una factura.

¿Por qué es importante tener una factura? La respuesta trivial es: ¡porque existe en la realidad! Pero si ustedes son pragmatistas y quieren una respuesta útil, verán que existen varios motivos, como tener que reimprimir una factura sin volver a calcularla, querer consultar cuanto se facturó (sumar todas las facturas), etc. Aún más interesante es que la factura me permita determinar los motivos por los cuales se llegó a los valores que posee, por lo tanto la factura no solo tendría los ítems facturados sino también podría, de alguna manera, permitirnos llegar a entender por qué se calcularon (importante al momento atender reclamos de los clientes, ¿no lo creen así?). En definitiva, necesitamos también una clase factura que será luego la que por pedido del ejercicio, se deberá imprimir en pantalla.

¿Qué sucede con la clase Cliente de la solución original?, ¿es una buena abstracción? Nuevamente debo responder que no. Posee varios errores respecto al ente que debería representar de la realidad. ¿Un cliente en la realidad, conoce todas las llamadas que hizo?, ¿ustedes como usuarios de teléfono, se acuerdan?, claramente no. No es la responsabilidad de un cliente conocer todas las llamadas que hizo. Menos aún porque si fuese así podría mentirle a la telefónica para tener que pagar menos, ¿no les parece? Este último argumento es válido para demostrar que un cliente ¡no puede tener la responsabilidad de imprimir su factura!, ¡sería una locura! Fíjense como el problema que estamos viendo en este caso no tiene que ver con cuestiones computacionales, no es un problema de performance, acoplamiento, encapsulamiento de datos, etc., es un problema de interpretación de la realidad, es un problema semántico, relacionado al significado que le otorgamos a los objetos, al lenguaje que construimos con nuestro modelo. Este último punto es el que marca la diferencia entre saber programar y saber programar con objetos. La diferencia radica en que programar con objetos implica entender el problema que estamos modelando, entender su significado y entender que por cada ente de este problema debe haber un objeto en nuestro modelo. No puede suceder que exista un objeto en nuestro modelo que represente un cliente y que dicho objeto no tenga nada que ver con un cliente real. ¿Se imaginan la reacción de un experto del dominio si le decimos que el encargado de facturar en nuestro programa es un cliente? No se deben crear objetos por cuestiones computacionales o de conveniencia organizativa, se deben crear si existen en la realidad que estamos modelando.

Ya estamos llegando al final, no se desanime. La verdad es que se necesitan unos cuantos objetos más, como el número de teléfono, alguien que se encargue de tipificar si una llamada es local, nacional o internacional a partir del número de origen y destino, etc., pero creo que a esta altura el objetivo del artículo está cumplido, que usted pueda responderse con sinceridad, sin necedad, si sabe o no desarrollar con objetos correctamente. ¡No se culpe sino es así!, es totalmente comprensible puesto que hay muy pocos buenos libros del tema, los cursos que abordan este problema generalmente lo hacen desde una perspectiva tecnológica con el objetivo de enseñar un lenguaje de programación, y sobre todo, es necesario cambiar la manera de pensar respecto de qué es un programa y cómo se debe crear un programa cuando se trabaja con objetos.

Lo importante es que usted recuerde por lo menos estas frases y trate de aplicarlas:

• Un programa es un modelo de un problema de la realidad
• Cuando se utiliza el paradigma de objetos para crear dicho modelo, se cuenta únicamente con objetos que representan entes de la realidad y mensajes que se envían entre sí para llevar adelante una tarea.
• Es muy importante descubrir qué objetos existen en la realidad y otorgar correctamente las responsabilidades a estos. Hacerlo permite reutilizar una solución.
• No todos los objetos están a la vista, hay que usar la imaginación para descubrir aquellos que existen implícitamente en la realidad. En otras palabras, hacer explicito lo implícito.
• Muchos de los objetos que no están a la vista, viven en la ambigüedad del lenguaje natural que usamos los seres humanos para comunicarnos y el la información contextual de una conversación. Es muy importante entrenar nuestra capacidad para encontrar estos objetos.
• La herencia o subclasificación es una herramienta poderosa pero pésimamente usada; en algunos casos dificulta el reuso.

Espero que hayan disfrutado de este artículo, por lo menos yo lo hice escribiéndolo. Si alguna vez quieren ver la solución completa del ejercicio vayan a la materia de Programación Orientada a Objetos que damos en la Facultad de Ciencias Exactas de la UBA o preguntenme!! jaja.