Principios de POO

Programacion orientada a objetos Es probable que te toque hablar con amiguetes que programan en la lengua de Mordor (visualbasic) o gente que programa en c ofuscado, o lo que es peor, desconocidos que te dicen que "programan" en HTML; estos intercambios de experiencias, esas afirmaciones sobre rendimientos de ejecucion pueden hacer tambalearse los cimientos de tu fe en la POO. Gracias a estas anotaciones rescatamos del olvido las excelencias de la POO y nos armamos de argumentos ante los herejes que nos salgan al paso con listados de codigo en ristre.

• Encapsulacion: los detalles de implementacion estan ocultos. Esto reduce que se reproduzcan errores cuando se hacen cambios. Se facilita enormementa la interaccion entre otros objetos encapsulados ya que no tienen que conocer los detalles de uso.

• Herencia: este mecanismo es una de las claves de la OOP. Todos los atributos, metodos, programaciones contenidas en una clase pueden heredarse y extenderse a otras clases facilitando la reutilizacion de codigo. Cualquier cambio se propaga en toda la jerarquia de clases y nos vuelve a ahorrar trabajo haciendo un sistema mas facil de mantener.

• Polimorfismo:gracias a el facilitamos la ampliacion del sistema ya que en lugar de crear codigo por cada tipo de dato lo podemos agrupar todo en uno utilizando la sobrecarga de funciones. El copy-paste puede parecer lo mismo, pero a la hora de cambiar/mantener un sistema se acaban metiendo muchas horas, cosa que con la POO evitas.

Bueno, imaginemos que queremos desarrollar un sistema utilizando la orientacion a objetos. ¿Por donde se empieza? Esta sería una aproximación: Todo proyecto comienza con una descripcion que encierra entre sus lineas los requerimientos del sistema. Es el momento de tomar un subrayador y abrir el tercer ojo; lo primero que debemos hacer es identificar objetos potenciales que formaran el diseño y es tan facil como buscar sustantivos (nombres, cosas). A veces no resulta tan obvio ya que los objetos pueden manifestarse de diversas maneras:

• Cosas

• Entidades externas (personas, maquinas o incluso otros desarrollos)

• Eventos (Cazo o zuzezo :>)

• Roles

• Lugares

• Organizaciones (dpto, division)

Debemos acotar los objetos en un dominio cerrado y ser capaces de identificar lo que esos objetos son, saben y hacen. Partiendo de la identificacion de objetos se puede ir desarrollando un diseño de clases usando simbolos o lenguajes unificados tales como UML. Aunque realmente no hay que forzarse, la POO no es mas que otra forma mas de abordar un problema; puede que el diseño OO te salga por instinto. No es de extrañar que un programador con años de experiencia acaba recurriendo a desacoplar cada vez mas sus modulos y a recurrir a patrones de software sin darse cuenta. Lo que no se puede negar es el auge de la POO viendo la proliferacion de lenguajes OO, o su adaptacion para tener las ventajas de su punto de vista (Java, php, python, perl,... son lenguajes "recientes")

A veces puedes liarte al tratar de distinguir clase y objeto; esta cita del profeta resuelve las dudas:

Mientras que un objeto es una entidad que existe en el tiempo y en el espacio, una clase representa solo una abstraccion,"la esencia" del objeto si se puede decir asi. Grady Booch

Figura: la incesante busqueda del santo grial...

En fin, estas anotaciones (eufemismo de TXAPA) sirven para acordarse de porque c++ puede ser una herramienta util.