Programación Orientada a objetos desde la perspectiva de su creador

Muchos mitos existen sobre la programación orientada a objetos. Una de las cosas que he escuchado diferentes versiones es sobre su creación. Yo prefiero pensar que todo ocurrió en el Centro de Investigación de Palo Alto (PARC - Palo Alto Research Center) de Xerox en 1970.

Alan Kay es el creador de la programación orientada a objetos. Es decir si utilizas poo debes conocer a esta persona.

Kay entró a trabajar en el Centro de Investigación de Palo Alto (PARC - Palo Alto Research Center) de Xerox en 1970. En los setenta fue uno de los miembros principales del centro, desarrollando prototipos de estaciones de trabajo en red, usando el lenguaje de programación Smalltalk. Smalltalk es un lenguaje de poo puro. En Smalltalk todo es un objeto, es de tipado dinámico y con clausuras. Deberían leer sobre este lenguaje.

Kay, junto a algunos compañeros en PARC y otros predecesores del Norwegian Computing Centre, es uno de los padres de la Programación Orientada a Objetos. Creó el Dynabook que definió la base de los ordenadores portátiles y Tablet PC actuales, también es considerado por algunos como el arquitecto de los sistemas modernos de ventanas interfaz gráfica de usuario.

Unas de las frases que más me gustan:

“I invented the term object oriented, and I can tell you that C++ wasn't what I had in mind.” —Alan Kay. (Yo inventé el término "orientado a objetos", y te puedo asegurar que C++ no era en lo que estaba pensando)

Dejo link: http://www.vpri.org

Encontrar los objetos apropiados

Cuando diseñamos, lo más dificil es encontrar objetos indicados que representen la realidad pero a la vez den flexibilidad a nuestros diseños como dice el libro Patrones de Diseño de Erich Gamma:

"Lo más complicado del diseño orientado a objetos es descomponer un sistema en objetos. La tarea es difícil porque entran en juego muchos factores: encapsulación, granularidad, dependencia, flexibilidad, rendimiento, evolución, reutilización, etc, etc. Todo ellos influyen en la descomposición, muchas veces de forma opuesta.

...

Muchos objetos del un diseño proceden del modelo del análisis. Pero los diseños orientados a objetos suelen acabar teniendo clases que no tiene su equivalente en el mundo real. Algunas de ellas son clases de bajo nivel como los arrays. Otras son de mucho más alto nivel... El modelado estricto del mundo real conduce a un sistema que refleja las realidades presentes pero no necesariamente las futuras. Las abstracciones que surgen durante el diseño son fundamentales para lograr un diseño flexible. "

Herencia frente a composición

Estoy leyendo Patrones de Diseño de Erich Gamma. En este libro discute sobre como es mejor reutilizar funcionalidad si por medio de la herencia o la composición. La idea de este post no es transcribir del libro sino hacer un resumen y analizar cada punto.

Vamos primero con la composición, la composición es una técnica en la cual descomponemos objetos para reutilizar funcionalidad. De esta forma componiendo objetos podemos obtener funcionalidad más compleja y completa.

Ventajas:

• Reutilización de caja negra, los detalles internos de los objetos no son visibles.
• La dependencia de objetos se puede definir dinamicamente si utilizamos interfaces. Disminuyendo el acoplamiento y aumentando la reutilización. 
• Ayuda a mantener cada clase encapsulada y centrada en una sola tarea. De esta manera, nuestra clases y jerarquías de clases permanecerán pequeñas y sera menos probable que se conviertan en monstruos inmanejables. 

Desventajas:

• Requiere más diseño (que tampoco es tan malo)

El mecanismo de herencia lo conocemos bien y también tiene sus ventajas y desventajas

Ventaja:

• Es facil de usar lo provee los lenguajes.
• Es más fácil modificar la implementación que esta siendo reutilizada. 

Desventaja:

• Reutilización de caja blanca, los hijos pueden modificar variables internas del padre (si están protegidas o publicas), la herencia suele decirse rompe el encapsulamiento. 
• Existe más acoplamiento ya que cualquier cambio en el padre obligara a cambiar la subclase. 

Según lo dicho podemos afirmar:

"Favorecer la composición de objetos frente a la herencia de clases."

Idealmente, solo crearíamos nuevos componentes para lograr la reutilización. Deberíamos ser capases de conseguir toda la funcionalidad que necesitamos simplemente ensamblando componentes existentes a través de la composición de objetos. Sin embargo, rara vez este es el caso, por lo tanto reutilizar mediante herencia hace más fácil construir nuevos componentes que puedan ser combinados con los antiguos. La herencia y la composición trabajan juntas. Pero abusar de la herencia trae consigo diseños más complejos y utilizar composición hace más fácil y reutilizable el diseño. 

Equals

Cuando creamos una clase es una buena práctica definir el método equals, dado que este representa con que campos se identifica esta clase; es decir dos objetos van a ser iguales si son iguales las propiedades usadas en el equals.

El EqualsBuilder de apache common nos puede hacer la vida más fácil a la hora de hacer los equals. Pero a la vez tenemos comprobaciones repetitivas que se pueden factorizar usando herencia.

Veamos un ejemplo de equals:

@Override
public boolean equals(Object obj) {
 if (obj == null)
  return false;
 if (obj == this)
  return true;
 if (!obj.getClass().isAssignableFrom(getClass()))
  return false;

 Author otherAuthor = (Author) obj;

 return new EqualsBuilder().append(this.user, otherAuthor.getUser())
   .isEquals();
}

Si hacemos otro equals vamos a hacer algo muy similar. Una forma de factorizar las lineas que se repiten es mediante herencia podemos hacer una clase padre de todas las clases del modelo que haga lo siguiente:

@Override
public boolean equals(Object obj) {
 if (obj == null)
  return false;
 if (obj == this)
  return true;
 if (!obj.getClass().isAssignableFrom(getClass()))
  return false;

 return businnessEquals(obj);
}

public abstract  boolean businnessEquals(Object obj);

Y businnessEquals sea abstracto y obligue a todas las clases del modelo a implementarlo. Todos los objetos que hereden de la clase abstracta deben implementar bussinnessEquals pero se olvidan de hacer las validaciones repetitivas.

@Override
public boolean businnessEquals(Object obj) {
 Author otherAuthor = (Author) obj;

 return new EqualsBuilder().append(this.user, otherAuthor.getUser())
   .isEquals();
}

Les gusto la solución? Se les ocurre otra?

Lenguaje de programación modernos

Un poco amarillista el titulo del post pero en los últimos años nos vimos bombardeados por nuevos lenguajes de programación como ruby, goovy, scala, ioke, python, etc. Y la verdad que están muy buenos.

Todo empezó con el bum de ruby, lenguaje script basado en smalltalk, que con railes parecía como que iba a conquistar el mundo. Pero otras plataformas no tardaron en copiar los beneficios del lenguaje para su plataforma así nació jruby, jython groovy (en java) y iron ruby y iron python (en .net).

Luego nació algo muy interesante la mezcla de paradigmas en particular la programación funcional con la programación orientada objetos, dando muy buenos lenguajes como scala, ioke o clojure en java y F# en .net.

En el blog se hablo de algunos de estos lenguajes:

http://emanuelpeg.blogspot.com/search/label/Clojure

http://emanuelpeg.blogspot.com/search/label/Ioke

http://emanuelpeg.blogspot.com/search/label/jython

http://emanuelpeg.blogspot.com/search/label/jRuby

http://emanuelpeg.blogspot.com/search/label/Lua

http://emanuelpeg.blogspot.com/search/label/Scala

Me quede pensando que esto esta buenísimo, la convivencia de diferentes paradigmas en un lenguaje, es raro que no se allá todavía inventado un lenguaje orientado a objeto y lógico como un prolog OO. Un ejemplo de esto es logtalk

¿Alguien conoce otro lenguaje multiparadigma?¿Alguien usa algun lenguaje multiparadigma?

Frases

"Los programas deben ser escritos para que la gente los lea y sólo incidentalmente, para que las máquinas los ejecuten."

---Abelson / Sussman

"Mucho del software hoy en día se parece a una pirámide egipcia: con millones de ladrillos apilados uno encima del otro, sin integridad estructural y hecho por pura fuerza bruta y miles de esclavos."

--Alan Kay

"Cualquier tonto puede escribir código que un ordenador entiende. Los buenos programadores escriben código que los humanos pueden entender."

--Martin Fowler

"Hay dos formas de diseñar software: la primera es hacerlo tan simple que obviamente no hay deficiencias y la segunda es hacerlo tan complicado que no hay deficiencias obvias. La primera forma es mucho más difícil."

--C.A.R. Hoare

"Si deseas empezar y desarrollar algo grandioso, no necesitas millones de dólares de capitalización. Necesitas suficiente pizza y Diet Coke en la nevera, una PC barata y trabajo y dedicación para realizar tu idea."

---John Carmack

La mejor forma de predecir el futuro es inventarlo.

--Alan Kay

El software y las catedrales se parecen mucho. Primero lo construimos, después rezamos.

–-Anónimo

this, self, Me y Yo!!!

this en un puntero a el mismo objeto. Bueno puntero en c++, para ser más generico es una referencia a si mismo, a nuestro mismo objeto. Por ejemplo:

this.hacerAlgo()

Es lo mismo que decir yo hago algo.
Este puntero a si mismo es muy útil. Ya que en un lenguaje no totalmente orientado a objeto. Como se que estoy llamando un método que esta dios sabe donde esta, o es un método que esta dentro de la clase. Con this queda mucho más claro.

Bueno this es en C++, java, php, javascript; es decir todos los derivados de c++.
self es en object pascal, simula, smalltalk y ruby.
Me es en visual Basic.

La verdad creo que es la primera (y va a ser la única) vez que diga que la gente de vb hizo bien las cosas. Me me parece más intuitivo, bueno self también esta bueno pero son 4 caracteres, mucho para escribir. Me es el ganador sin duda, intuitivo y corto.

Auque no entiendo porque ningún lenguaje uso I, es intuitivo y corto. Si programáramos en castellano seria “yo” que a mi por ser de lengua española me gusta más.
Por ejemplo podría escribir:

yo.voyAHacerAlgo();

Y ustedes, ¿que piensan cual es la palabra que les gusta más para referirse a nuestro mismo objeto? ¿this, self o Me?

Inyección de dependencias

Originalmente, La inyección de dependencia se la llamaba de otra forma: inversión de control (IoC). Pero en un artículo escrito por Martin Fowler preguntaba qué aspecto del control se estaba invirtiendo. Llego a la conclusión de que la adquisición de la dependencia lo que se invertía. Basándose en esa revelación, acuño la frase “inyección de dependencia”, un término que describe mejor lo que ocurre.

Pero ahora bien ¿ qué es la inyección de dependencia? La wikipedia nos dice algo así: http://es.wikipedia.org/wiki/Inyección_de_dependencias

Cualquier aplicación no trivial está formada por dos o más clases que colaboran entre sí para realizar alguna lógica. Tradicionalmente cada objeto se hacía cargo de obtener sus propias referencias a los objetos a los cuales colaboraba (sus dependencias). Esto lleva a código acoplado y difícil de probar.

Cuando se aplica inyección de dependencia le decimos a una entidad externa que provea las dependencias a los objetos. Esto nos resuelve el problema del acoplamiento.

El acoplamiento es un mal necesario ya que sin él los objetos no podrían interactuar para resolver problemas, pero cuan menor sea el acoplamiento es más reutilizable, comprobable y flexible.

La ventaja clave de inyección de dependencia es el acoplamiento débil. Si un objeto solo conoce sus dependencias mediante su interfaz (no su implementación o como fueron definidos) entonces la dependencia puede intercambiarse con una implementación diferente sin que el objeto dependiente sepa la diferencia.

Por ejemplo si defino una interfaz la implementación de la misma pude ser un objeto plano, web service, objeto remoto, etc.

Inyección de dependencia es la llave para minimizar el acoplamiento.

POO = Herencia

Cuando pensamos en POO siempre caemos en que cuanto más usemos herencia más orientado objeto esta. Y claramente no es así. Es decir si tenemos este pensamiento estamos comenzando con el pie izquierdo; estamos pensando en "programación orientada a clases". Claro estamos generalizando de ante mano.

Lo ideal (que no quiere decir que en el día a día lo haga) es imaginar el problema con solo objetos. Una representación del problema; como una simulación. Sin interesarnos en clases, datos, etc.

Luego que ya entendimos el problema; pensamos como se comportan los objetos. Hay objetos que se comportan similar y los podemos generalizar entonces tenemos nuestra clase!!!

Hora tenemos un conjunto de clases y vemos que algunas tienen el mismo comportamiento, entonces podemos generalizar en una clase padre.

Claro esta que esto en teoría es muy fácil, el problema es la práctica. Veamos un problema aparentemente fácil, una academia donde tenemos alumnos y profesores. Fácil no? Una clase persona de la cual heredan la clase Alumno y Profesor. Muy fácil !!!

Momento ... y si un alumno también es profesor. Mmm... NO era tan fácil.

Con el modelo presentado hacemos agua, donde estuvo el error el primer paso, NO ENTENDIMOS EL PROBLEMA!!!

Lo escrito no es un descubrimiento filosófico ni un pensamiento que va a cambiar tu vida profesional. Simplemente una reflexión y recordatorio, antes de pensar en herencia y clases; pensemos: ¿entiendo el problema?