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

Empecemos ahora a analizar una solución del ejercicio que plantee la semana pasada.

Del enunciado se deduce claramente que es necesario representar llamadas locales, nacionales e internacionales. Como todas ellas son llamadas, lo más lógico es usar “herencia” de tal manera que tengamos una clase abstracta a la que denominaremos “Llamada” y tres subclases, una para representar las llamadas locales (LlamadaLocal) otra para las nacionales (LlamadaNacional) y otra para las internacionales (LlamadaInternacional).

A partir de estas tres clases concretas podemos empezar a resolver el ejercicio, otorgando a dichas abstracciones la responsabilidad de devolver su costo. Para ello, está claro que debemos implementar el método “costo” en estas tres clases (seguramente será un método abstracto en Llamada).

Pensemos ahora como sería la implementación de este método. Para que una llamada pueda devolvernos su costo, es necesario que sepa cuánto duró y en que momento se hizo (hora y día). Indudablemente estos deben ser colaboradores (variables de instancia) de las llamadas, de esta manera pueden ser utilizados en la implementación del algoritmo del costo. Como pueden ver, el ejercicio es muy trivial. Una vez resuelto cuales son las abstracciones principales que debemos tener y la funcionalidad más importante (calcular el costo), el resto no posee casi importancia.

Para terminar de resolverlo, es necesario imprimir por pantalla algo que muestre el abono mensual, el costo de las llamadas y por último un total. ¿Dónde podemos ubicar este código? Luego de pensar un poco queda claro que es necesario tener algún objeto que represente a un cliente, el cual contendrá la colección de llamadas realizadas y la implementación del método “imprimirFactura”. Creo que no hay duda que dicho objeto es el lugar más conveniente para implementar esta funcionalidad.

Una posible implementación de algunos métodos sería (utilizando Java)

Class Cliente
{
private Llamada[] llamadas;
public Cliente (Llamada[] llamadas)
{
this.llamadas = llamadas;
}

public void imprimirFacturas( Date fecha)
{
imprimirAbono (fecha);
imprimirCostoDeLlamadas (fecha);
…. //etc.
}
}

Resumiendo, tenemos clases que modelan las llamadas (una para cada tipo) y tenemos la clase Cliente que permite imprimir las facturas y conocer las llamadas que realizó. Se puede observar que las “estructuras de datos” presentadas son sencillas y las relaciones entre ellas son bastante lógicas.

A esta altura del partido, usted se puede estar preguntado: ¿Por qué utilizo este ejercicio como ejemplo de este artículo y en las entrevistas si es tan sencillo? ¿Acaso un ejercicio tan sencillo puede ocasionar problemas? La solución presentada es directa, con estructuras claras, objetos sencillos, ¿no es acaso una buena solución? ¿No es acaso similar a la solución que usted pensó? ¿No es la solución que usted presentaría si estuviese en la entrevista o haciendo el parcial de la facultad?

La verdad es que este ejercicio tan sencillo demuestra rápidamente el conocimiento sobre el paradigma de objetos que posee una persona. Si usted cree que la solución presentada es una buena solución, le pido disculpa por lo que le voy a decir, pero entonces usted no sabe desarrollar con objetos. Siento decírselo de manera tan ruda y directa, pero la verdad es que esta solución (que hace el 90% de las personas) es una pésima solución, está plagada de errores de interpretación y modelado; es una solución que no aprobaría el parcial de la facultad.

En este momento usted puede estar experimentando varios sentimientos. Puede estar sorprendido por lo que digo e interesado en conocer por qué, o puede estar molesto y pensar que esta leyendo burradas. Le pido un poco de paciencia, que trate de seguir leyendo para ver si concuerda o no con mi punto de vista.

Le comento que encaré este artículo pensando en producir una molestia en el orgullo del lector y así lograr que no se olvide fácilmente de él. Otro objetivo es que usted vea un mal ejemplo, puesto que muchas veces es mejor aprender de los errores.

Mañana posteo como sigue esta historia...