Blog de Alejo

Hola, esta es la segunda parte de la serie de articulos sobre POO (aca tienen la primera).

Hoy en dia hay muchos lenguajes de programacion, y cada uno de ellos trae sus propios elementos que los caracteriza. En Java tenes un synchronized, en PHP tenes arrays asociativos y foreach, en C++ tenes dynamic_cast<T>(P), en Pascal tenes la sentencia New y en Python, lambdas. Al mismo tiempo, en los lenguajes que respetan la POO, existen las clases. Sin embargo, y a diferencia de lo que mencioné antes, las clases por si solas no tienen ninguna funcionalidad definida, uno mismo como programador debe darle una utilidad.

Las clases son un mecanismo de abstraccion, permiten cambiar el foco de atencion en el codigo a medida que uno programa. En el articulo anterior en el ejemplo de las frutas y las bananas, cuando no me interesa saber de que fruta estoy hablando, no necesito saberlo. La idea es que uno no tenga que pensar en Bananas, Manzanas, Peras, Duraznos y Ciruelas. Tengo frutas, muchas, pocas, no interesa.

Ahora bien, una fruta tiene muchas propiedades y caracteristicas. Podemos pasarnos una vida entera diseñando una clase generica para realizar la abstraccion de una Fruta, y aun asi no conseguiriamos tener una totalmente completa; tendriamos que modelar las particulas subatomicas de las moleculas que componen la fruta, las propiedades y la forma que interactuan con lo que las rodea.

Hacer eso no es lo que da.

La idea de hacer clases es que simplemente cumpla con nuestro proposito. Si no nos interesan las particulas subatomicas, y solo queremos poder diferenciar aproximadamente una Fruta de un Perro, con hacer dos clases muy simples deberia alcanzarnos

El proceso de decidir que Clases deberiamos hacer en nuestro programa, que clases NO deberiamos hacer en nuestro programa, y la forma en la que los objetos interactuan se llama Diseño. Un Diseño Orientado a Objetos es una lista claramente definida de Clases y Objetos, junto con la forma en la que estas Clases y Objetos interactuan.

• ¿Hago una jerarquian de clases, o una sola clase que se encarga de todo?
• ¿Esta funcion en que clase la pongo?
• ¿El perro se come la fruta, o la fruta le dice “comeme” al perro?

Responder esta clase de preguntas es la parte mas dificil al momento de “Programar”. Esto es asi porque la programacion es un 99% artesanal. A diferencia de las matematicas o de la fisica en donde hay reglas claras y bien definidas sobre como hacer algo, en la informatica no existe nada parecido, ni mucho menos existen balas de plata; aun nadie encontró ningun Santo Grial. Y el 80% de los problemas en todo el “Proceso de Desarrolo de Software” son problemas sociales. Gente. Personas. Animo. Humor. Clima.

Es por eso que XML no es la solucion a todos tus problemas. Y es por eso que hay codigos “Lindos” y codigos “Feos”. Todo termina siendo una cuestion de costumbres, gustos y necesidades del momento.

Existen buenas costumbres y existen malas costumbres. Usar patrones de diseño generalmente es una buena costumbre. ¿Que es eso? Son guias o sugerencias escritas por alguien, quien recomienda que en determinada situacion uno haga cierto grupo de clases, relacionadas de alguna forma especifica. Por ejemplo, si uno tiene que hacer un programa que represente una videocasetera, existe un patron de diseño llamado State el cual se utiliza para representar el estado (encendida, apagada, reproduciendo, rebobinando, grabando, etc) de una forma elegante, clara y (aproximandamente) sencilla. Un documento XML es claramente un Composite, y si queres modelar “Roles” podes usar un Role Object. Hay muchos otros, y cada tanto alguien “descubre” uno nuevo. Para mas informacion hay un libro llamado Patrones de diseño.