Showing posts with label interfaces. Show all posts
Showing posts with label interfaces. Show all posts

Wednesday, April 08, 2009

Por que usar interfaces en .NET

¿Por que usar interfaces en .NET?

Es la pregunta que siempre aflora cada vez que te encuentras implementando un modelo de clases que se ajuste a la realidad de negocio para el cual debes encontrar una solucion y en la que estas involucrado.

La Programacion Orientada a Objetos, aka POO, nos enseña que uno de los pilares de su existencia es la herencia, en sentido estricto: la herencia multiple.

La herencia multiple de clases es una bondad de la POO, pero al tocarse con la cruda realidad encuentra dificil su implementacion, sin brindarle estabilidad al modelo de clases construido.

Dificil implementacion en el sentido, de una flexibilidad atroz, que en algun momento escape de nuestro control y permita la construccion posterior de comportamientos NO concebidos por el negocio, plasmadas en la construccion de ese modelo de clases que vienes implementando.

La herencia multiple permite que pueda converger en una sola entidad diferentes comportamientos que muy probablemente colisionen sin tener mayor control sobre esa futura mutacion.

Esa flexibilidad se acota en .NET, al permitir solo la herencia simple de clases, NO la herencia multiple.

Los lenguajes de desarrollo en .NET dejan de ser, por eso, lenguajes orientado a objetos como mandan los canones :)

Fue una decision de diseño del CLR Team y el equipo de C#, que se tomo en algun momento, luego de evaluar las debilidades de un leguaje orientado a objetos quimicamente puro, como el precioso C++, por ejemplo.

Por su parte, la teoria de la POO, ya concebia la definicion de interfaces, de una manera distinta. Las clases abstractas son, en la actual implementacion de los lenguajes orientado a objetos, las famosas interfaces con una restriccion: que cada metodo de dicha clase abstracta sea de orden publico.

Las interfaces nacen alli. Y al tener su implementacion en control de quien construye el modelo de clases, de tu producto de software, se permite a nivel de diseño heredar multiples interfaces.

Las interfaces son esa valvula de escape de un lenguaje orientado a objetos que NO permite herencia multiple de clases, con la ambicion de serlo a regaña dientes.

Pero, ¿por que usar interfaces en .NET?

Al utilizar interfaces y definirlas en nuestro modelo de clases estaremos permitiendo la posibilidad de aprovechar las bondades de un lenguaje orientado a objetos en .NET, en beneficio de una mejor implementacion del producto de software.

Una de esas tantas bondades es el polimorfismo.

¿Que beneficio encontrare al utilizar las interfaces?

Tiempo, simplemente. ¿Te parece poco, pregunto?

El uso de interfaces que definen comportamientos, que aquellas clases que las hereden deban establecer su correcta implementacion, eleva tus posibilidades de reducir los tiempos en la construccion del software, abrumadoramente.

Orientar la implementacion de tu modelo de objetos en funcion a la herencia simple de clases apoyada en la herencia multiple de interfaces, para el uso de estas en el envio de informacion entre las clases de tu propio modelo, para la definicion de tus Templates y para el manejo apremiante de delegates, te permitiran alcanzar un nivel de abstraccion, en el diseño y la arquitectura de tu modelo de clases, que se vera reflejado en reducir los tiempos para desarrollar tu producto de software y por ende los costos.

De nada sirve tipear codigo a diestra a siniestra, que promueve el COPY & PASTE por everywhere, haciendo del codigo un telaraña dolorosamente mantenible y vergonzosamente presentable.

Si NO defines tus propias interfaces en el modelo de objetos que haz diseñado, NO estaremos avanzando, solo retrocediendo.

El dolor vendra la proxima vez que tengas que meterle mano a esa basura de codigo, donde las clases que tienen comportamientos similares esten implementadas de formas totalmente distintas, sin guardar coherencia entre si, NI centralizar las lineas bases de dicho comportamiento.

Solo te quedara exclamar: Esos cambios son muy drasticos...!!!

Saturday, January 26, 2008

Usando Interfaces en Linq To Sql

Una de las cosas que me incomoda de Linq To Sql, es que no brinda la posibilidad inmediata de construir un modelos de clases orientada al uso de Interfaces.

En terminos sencillos, Linq To Sql te brinda un modelo de clases basada en el modelo entidad relacion de tu base de datos.

Si el objetivo es llenar un GridView y mas nada. Seguramente estaras contento con Linq To Sql. Pero si no. Uhmmm.

Un producto de software no solo es llenar GridViews. Es mucha más que solo aquello.

Las reglas del negocio traen como consecuencia contruir un modelos de clases basada en la implementación de Interfaces: IUser, IGroup, IPurchaseOrder, IInvoice and others.

Te das cuenta. ¿Por que? Pues porque es la forma profesional de construir software.

Pero me quita tiempo. Dicen algunos. Si pues efectivamente, construir software no es hacer click and click.

¿Cual es el objetivo desde la perspectiva de nosotros, los Jefe de Proyecto?. Pues que el producto de software pueda escalar en el mediano y corto plazo. Desde el punto de vista tecnico. Sin embargo desde el punto de vista comercial, de la casa de software, es entregar el producto a tiempo.

Estas dos posiciones se contraponen y se enfrentan en algun momento.

Y es justamente el Jefe de Proyecto, quien ponen de manifiesto toda su capacidad para satisfacer ambos objetivos.

En consecuencia, Linq To Sql nos esta nativamente orientada a satisfacer el objetivo tecnico. Esta orientada mas al otro objetivo, el comercial.

Entonces ¿que hacer?. Meterle mano para que tu producto de software pueda ser escalable en el tiempo. Y sino quiero. Pues click and click. Tranquilo, no se te quemara neurona alguna. Je!