POO, para que se lo cuentes tu vieja

Bueno, como todos saben la programación orientada a objetos es algo que esta en boca de todos, en mente de una menor cantidad de personas y en comprensión de aun menos.

La razón de esto no es que sea algo muy complicado, sino que hay muchas literaturas controversiales, montones de conceptos cruzados, banda de blogs que la explican cosas a partir de tecnologías, niños que creen en los gurues y pelotudos que se creen gurues.

Lamento ser yo quien se los diga: los gurues son los padres, ninguna idea es definitiva, no hay cookbook para la programación de verdad.

Una vez planteado esto, la mejor forma, a mi manera de ver las cosas, de explicar POO es partiendo de una analogia de lo más básico.

Hacer un programa orientado a objetos se trata ni mas ni menos que de concebir entes con comportamiento y hacer que se relacionen entre ellos concibiendo asi un ente aun mas grande al que se le puede pedir que resuelva los problemas que tenemos que resolver.

Ok, tu vieja por ahi asi no lo entiende, vayamos a una analogía:

Suponete que tenemos que construir un edificio ¿Qué necesitamos? Bueno, basandonos en un sistema de trabajo clásico, uno necesita albaniles con distintos conocimientos: levantar paredes, hacer cimientos, hacer columnas, etc. Tambien necesita especialistas de instalaciones: Plomeros, electricistas, gasistas etc. Además necesita supervisores que sepan controlar y tomar decisiones que no pueda tomar el albanil por que no le corresponde (sea por falta de conocimiento o por estar fuera de su responsabilidad), a eso le podemos agregar un ingeniero y/o arquitecto encargado de las decisiones mas generales. Finalmente agregamos diseñadores de ambiente para la parte estética.

Para mantener acotado el ejemplo no vamos a preocuparnos por los materiales y la lógistica de los mismos, supongamos que estan ahi y son infinitos.

Ahora mismo entonces tenemos un monton de gente (entes) que sabe hacer su tarea (reponsabilidad) y que hay que organizar (relación) para que trabajen juntos para resolver los problemas propios del negocio de la construcción.


Que es lo mas importante del ejemplo:

1. una responsabilidad a grandes rasgos en POO suele estar definida por uno o mas objetos relacionados (asi como levantar una columna implica varias personas de distintos conocimientos trabajando juntos). 
2. La relación entre los distintos responsables esta dada por el dialogo entre los mismos (envio de mensajes) Obvio, ¿No?
3. Cada responsable es un pequeño sistema en si que forma parte de uno mas grande que es el encargado de resolver el problema.
4. El mismo plomero puede trabajar en esta obra o bien cambiando el cuerito de la canilla de tu casa, así como los mismos objetos se pueden usar en varios problemas donde calcen.

Ahora, que es lo que no es extrapolable de este ejemplo:

1. He escuchado muchas veces 'orientación a objetos es programar la realidad', ok, por suerte eso es mentira, si fuese verdad nunca se hubiese terminado de hacer el primer programa. Solo se programa lo que se necesita. En este caso las relaciones informales - sociales no nos importan.
2. He escuchado tambien muchas veces que la definición de los objetos esta dada por la realidad. Pero bue, al final uno tiene que mandar un mail basandose en un protocolo que no tiene nada que ver con la realidad, o tiene que hacer un editor de texto y de pronto no existe algo así en la realidad. Al final lo mas razonable es evitar el exceso de realidad y tratar de armar una realidad adhoc.
3. No existe necesariamente una "cadena de mando" (Suena re milico) en la programación.