Showing posts with label software. Show all posts
Showing posts with label software. 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...!!!

Monday, April 06, 2009

Tres capas desarrollo software arquitectura

Desarrollar software permite la posibilidad de crear, algo que NO necesariamente existe en el entorno inmediato, para reutilizar y hacer que funcione en la cruda realidad: produccion.

El entorno de produccion es aquel siniestro lugar al cual estamos sentenciados y nos dirigimos cada vez.

Diseñar una arquitectura que nos permita cierta flexibilidad y la vez rigidez en su propia base ayudara a que nuestra implementacion y posterior deployment este bajo nuestro control.

Si algo escapa de nuestro control, todo sera un dolor de cabeza.

Una de estas arquitecturas es el desarrollo sobre Tres Capas, muy conocida por cierto, excesivamente utilizada y pesimamente implementada, la mayoria de las veces.

En el diseño de una arquitectura, debes concebir que la capa inferior facilite las tareas de la capa superior, y que esta la utilize de manera simple y natural.

Aquella es la idea, su razon de ser.

NO debe exisitr redundancia de operaciones entre una capa y la otra. De lo contrario, NO tendria mayor valor NI significado su existencia.

Por ejemplo, en el clasico y trivial ejercicio, donse se requiere sumar dos numeros enteros ubicados sobre un WebForm, en el cual se debe ingresar los datos sobre un par de controles TextBox y un boton que ejecute la operacion para que se muestre el resultado en otro TextBox establecido en modo readonly, muy probablemente te encuentres con un diseño de tres capas, similar a este:

private void Sumar_Click( Object sender, EventArgs e )
{
BLSumar o = new BLSumar();
this.c.Text = BLSumar.Calculate( this.a.Text, this.b.Text );
}

De esta manenra, la clase BLSumar, donde BL nos quiere decir Business Layer, tendra, muy probablemente, una implementacion como esta:

public class BLSumar()
{
public Int32 Calculate( Int32 a, Int32 b )
{
DLSumar o = new DLSumar();
return o.Insert( a, b );
}
}

Del mismo modo, la clase DLSumar, donde DL nos quiere decir Data Layer, ajustara su implementacion en algo similar a esto:

public class DLSumar()
{
public Int32 Insert( Int32 a, Int32 b )
{
Store procedure = new Store( "SP_SumarInsert" );
procedure.AddInParameter( a );
procedure.AddInParameter( b );
procedure.AddOutputParameter( "c" );

Helper.ExecuteNonQuery( procedure );
return procedure.Parameters[ "c" ].Value;
}
}

Asumiendo, para los efectos de la explicacion, que existe una Tabla en la Database con tres campos, donde los dos primeros seria los sumandos de la operacion y el tercero un campo calculado que obtiene la suma aritmetica de los dos primeros, entonces continuamos :)

En este supuesto escenario, ¿cual seria la razon de ser del Business Layer que funciona de mero wrapper del Data Layer?

Recuerda que aun falta la implementacion del Store Procedure que es llamado desde la clase DLSumar, que en teoria debe realizar un simple INSERT sobre la tabla Suma.

¿Tantas clases y un store procedure para realizar una operacion tan simple?

Por Dios! Nunca fue tan laborioso realizar una operacion contra la Database :)

Definitivamente, algo anda mal. Ten la plena seguridad que NO estamos haciendo las cosas bien.

La solucion poco decorosa de una implementacion sobre Tres capas, de esta manera, solo provoca que se gasten lineas de codigo entre una capa y otra, sin mayor valor agregado para los efectos del resultado final.

Aplicando el mismo criterio para la construccion de tus clases, en la vida real, donde te has de encontrar con un mayor numero de tablas y un abrumador numero de campos por cada tabla, entonces nos damos cuenta que nuestra solucion es una verdadera porqueria :)

La correcta solucion pasa por darle a la implementacion de cada capa un valor agregado que facilite la vida de la capa superior. NO redundar con la misma operacion, en contextos distintos.

Una implementacion de esta manera, promueve el COPY & PASTE.

Si ello sucede en la construccion de tu producto de software, estate seguro que nuestro desarrollo camina a piñon fijo hacia una pesima escalabilidad con el codigo disgregado por everywhere.

Dolorosamente sostenible en el tiempo, aburridamente mantenible y vergonzosamente presentable :)

Monday, August 25, 2008

Bottom Up para desarrollar software

La perspectiva Bottom Up para desarrollar software provoca que una de tus primera tareas sea modelar la estructura logica de la Base de Datos que soportara el producto de software que vayas a construir.

Muchas veces se cae en la simpleza de mencionarse que si la base de datos esta bien modelada cualquier cambio posterior NO tendra un impacto muy grave.

Los que estamos involucrados en el mundo del desarrollo de software con conectividad a Base de Datos, hemos modelado una estructura de datos, si o si, y hemos visto hasta Base de Datos en produccion, sin primary keys, constraints, relations ships, sin nada.

Con campos redundantes de informacion de una tabla en otra, entre quienes existen solo algun tipo de relacion.

Entonces, ¿hasta que punto es valido rasgarse las vestiduras para aferrarse a la fragil idea de que la base de datos debe estar MUY bien modelada?

En la fase de la contruccion del software, aquella en la que los developers empiezan su tarea, desarrollan las vistas del usuario y demas, por alguna u otra circunstancia se haran necesarios diferentes cambios en la estructura de datos original de la base de datos que hayas modelado.

NO existe el modelamiento preciso y exacto que resuelva todas las incidencias posteriores, sin requerirse cambios en los objetos de la base de datos: tablas, campos, relaciones, etc.

Si aun puesto en produccion, el software al ser usado por un mayor volumen de usuarios, brotaran incidencias que traeran como consecuencias cambios en las vistas y muchas veces -algunos de esos cambios- requeriran cambios en la estructura de datos original, pues con mayor razon que en la fase de la construccion del software seamos testigos presenciales y activos de esos cambios.

La Base de Datos NO tendria por que ser necesariamente la mayor de las prioridades, pues las vistas del usuario NO interacturan directamente con dicha estructura.

La capa de negocio o Business Layer adquiere mayor relevancia.

Wednesday, August 20, 2008

Web Client Software Factory

Una propuesta para desarrollo de software en modalidad web con la propuesta Model View Presenter MVP, es el llamado Web Client Software Factory.

Este interesante add-on para el Visual Studio .NET 2005 propone una forma peculiar de desarrollar software para ASP.NET.

Web Cliente Software Factory se monta sobre el Composite UI Application Block.

Esto es una ladilla pues cuando te encuentres desarrollado alguna vista en particular te encontraras con un error mas deconocido que el anterior.

Unos errores realmente espantosos.

Ello es consecuencia directa de utilizar el Composite UI Application Block como base para el Web Client Software Factory.

Por otro lado, el Web Cliente Software Factory propone un marco para desarrollo de una aplicacion ASP.NET en lo correspondiente a la capa del usuario. El manejo de las vistas a traves de un presenter.

Escucharas sobre Presenters, Controllers y Views a diestra y siniestra.

Sin embargo, debes y tienes que encontrar una forma creativa de fusionar la propuesta del Web Client Software Factory con tu capa de negocio y posteriormente con tu capa de acceso a datos.

De una forma u otra, sentiras en carne propia que requieres utilizar mas tiempo -que el que utilizabas antes- para construir un aplicativo cualesquiera bajo la propuesta del Web Client Software Factory.

Los Views solo deberian gestionar los eventos de los controles que estan disponibles al usuario.

Los Presenters son los encargados a establecer la logica de presentacion de la informacion en los Views. Pues los Presenters tiene una referencia a los Views.

Esto podria sonar relativamente extraño, pero es asi. Pues uno espera que sea el View que tenga una referencia al Presenter, sin embargo la referencia es a la inversa y eso ayuda a poder utilizar los elementos definidos en los Views desde el Presenter.

Los Controllers hacen justamente eso, controllar la forma en que los Presenters han de interactuar.

Sin embargo, queda en un limbo como hacer para que tu Business Layer se integre facilmente con la propuesta del Web Client Software Factory.

Cada quien tiene su propio criterio y encontraras soluciones buenas y otras NO tan buenas.

En el intento esta la respuesta. Y en las pruebas de stress la mejor solucion.

Wednesday, July 23, 2008

Top Down versus Bottom Up

Cuando desarrollamos software con conectividad a Base de Datos, nos encontramos con diferentes herramientas, en el mercado, que facilitan la construccion de los Business Entities a partir de una estructura de datos relacional.

El resultado es alentador. Gracias al Drag & Drop o algo relativamente similar obtenemos los Business Entities para el mundo .NET desde el conjunto de tablas que se encontraban ya definidas en la Base de Datos.

Esta es una perspectiva Bottom-Up.

Pues partimos del nivel mas bajo de la arquitectura de un producto de software, la Base de Datos, para facilitar la contruccion de las demas capas de la arquitectura, aquellas que estan por encima de la Base de Datos.

Pero existe la posicion contraria. Un punto de vista distinto, llamado Top Down.

A partir del cual prototipeamos las interfaces de usuario, con las cuales este -el usuario- ha de interactuar con el producto de software que vayamos a construir, para ir construyendo conceptualmente las demas capas de nuestra arquitectura de software.

Seguidamente un modelo de clases que se desprendera a partir de la discusion y analisis de los casos de uso, sera nuestro siguiente paso.

Dicho modelo de clases orientados al negocio del producto de software, que tenemos la mision de construir, estan relacionados en funcion a: herencia, asociacion, agregacion y otros mecanismos de relacion los cuales NO necesariamente deberian plasmarse tal cual en la estructura de datos final, ya en la Base de Datos.

Y he aqui la moraleja.

Ambas perspectivas tienen sus pros y contras, cada una de ellas validas desde sus respectivos puntos de vista.

Pero ambas perspectivas: Top Down y Bottom Up, se encuentran en ese punto. Aquel punto donde la conciliacion es el mejor fusible, para tener contentos a la mayoria, pero NO siempre la mejor solucion.

Para Bottom Up un Business Entity en terminos sencillos deberia ser tal cual una tabla que esta definida a nivel de Base de Datos. Tantas propiedades en cada Business Entity como columnas existan en la tabla correspondiente.

Por otro lado, Top Down propone algo diferente pues la relacion de una herencia o una agregacion a nivel de un modelo de clases de negocio NO se plasman tan facilmente a nivel de Base de Datos.

Menudo problema.

Sunday, February 03, 2008

El arte de construir software

El desarrollo de software es un arte. El don de hacerlo simple y facil, pocos seres sobre la faz de la tierra pueden materializarlo.

La posibilidad de gestionar personas es una tarea algo distinta.

Hacerlos sentir a cada uno de ellos importantes. Coger sus buenas ideas y canalizarlas de alguna forma para que se sientan participes activos del producto a construir, es el reto.

Como Jefe de Proyectos tu requieres el cumplimiento de ciertas tareas, por parte de tus desarrolladores, lo mas ajustado al cronograma.

Pero existen ciertas tareas encomendadas que por su relativa complejidad requieren de tu apoyo.

Te encontraras con algunos que su idea, ciertamente, es buena. Solo debes ajustarla un tanto para que pueda engranar con el contexto. Recuerda, tu tienes la vision del bosque.

En otro casos, los más operativos aquella ideas no tienen mucho sustento. Se basan en un clasico COPY & PASTE luego un SEARCH & REPLACE para finalmente, tu al ver toda esa mazamorra, hacerle un SHIFT + DEL.

En fin, lo que sucede es que desarrollar software no es hacer CLICK & CLICK. O un nada ingenioso COPY & PASTE. Se requiere de cierto talento.

Dentro del mundo de los developers, ver algo distinto e interesantemente construido, por lo general se le califica, como "fumada", a primera vista. Pero luego se dan un tiempo para analizarlo y verlo detenidamente, y terminan por llamarlo: arte, en ciertos casos.

Y ese es el meollo del asunto desde un punto de vista lirico.

Cuando se requiere el cumplimiento de las tareas para ayer. Bienvenido tu COPY & PASTE, pero entonces saltara una pregunta. ¿Por que aceptaste una fecha asi?