Parte III: ¿Conoce usted qué significa desarrollar con Objetos?

Analicemos ahora por qué no es una buena solución. La verdad es que hay varios motivos. El primer error grave es crear una clase por cada uno de los tipos de llamadas. ¿Por qué?, porque hacerlo implica realizar una categorización sobre las llamadas que no es “esencial” a la llamada en si, sino accidental a la tipificación utilizada para facturar su costo. Crear estos conjuntos de clases implica asumir que las llamadas en todo contexto, deben saber responder su costo, cuando quizá no sea importante para otro problema. Usted seguramente dirá: “el ejercicio habla sobre obtener el costo de las llamadas, ¿por qué debería preocuparme sobre como serán utilizadas las llamadas en otro problema o contexto?”. Justamente una de las características de trabajar correctamente con objetos es saber interpretar la esencia de los mismos, para que luego puedan ser reutilizados en distintos contextos. Es por este motivo que trabajar con objetos correctamente permite “reutilizar código”, esa famosa característica que se vendió del paradigma y que fue pésimamente relacionada con la “herencia”. Acá estamos viendo un ejemplo claro donde la “herencia” va en contra del reuso, puesto que esta solución no serviría para un sistema de marketing de llamadas, para nombrar un caso.

¿Qué es, entonces, la esencia de un objeto? Responder esta pregunta es meternos en un tema más bien filosófico que computacional, pero créanme que programar tiene mucho más de filosófico de lo que creemos. Para dar una respuesta más o menos rápida, debemos entender que un objeto es una “representación” de un “ente” de la realidad. En otras palabras, un objeto en mi programa debe existir solo si existe un “ente” en la realidad que sea representado por dicho objeto. Ustedes dirán, “pero si tenemos llamadas locales, nacionales e internacionales, ¿cuál es el problema en tener esas tres clases?”. El problema es que estamos confundiendo la finalidad de la herramienta denominada “herencia” o “subclasificación” con la categorización de objetos. Este error se repite constantemente porque la subclasificación implica categorización, sin embargo la inversa no es verdad y es muy común ver que los programadores utilicen “herencia” para resolver todo problema de clasificación, como en este caso, donde es necesario clasificar las llamadas en locales, nacionales e internacionales.

Repasemos un poco lo dicho hasta ahora. Vimos que no está bien tener una clase por cada tipo de llamada porque el motivo de esta clasificación no corresponde a las llamadas en sí, sino al problema de facturarlas. Hacerlo impide su reutilización en otros contextos. Veamos ahora un punto de vista distinto. Qué sucedería si tuviera una sola clase, por ejemplo Llamada, y tres conjuntos (no importa si están implementados con un vector, lista, diccionario, etc.), uno para las llamadas locales, otra para las nacionales y otra para las internacionales, ¿no se solucionaría el problema de la clasificación de llamadas? La realidad es que sí, con algunas ventajas adicionales, como poder mover una llamada de un conjunto a otro fácilmente, o que una llamada pueda estar en más de un conjunto a la vez (seguramente un conjunto de otro problema o contexto, como por ejemplo tipificar llamadas por duración). En definitiva una solución que posee menos “acoplamiento” entre la llamada y su tipificación (¿se acuerda de la frase “máxima cohesión, mínimo acoplamiento”?).

Mañana veremos como solucionar el problema del costo con esta nueva solución.