miércoles, 24 de agosto de 2011

El principio de la unica responsabilidad

Las clases solo deberian tener una responsabilidad, una tarea, conocer una cosa. Mas concretamente no deberia haber mas de una razon para cambiar una clase.
Considera la siguiente figura, esta clase conoce demasiado. Sabe como calcular un total y los impuestos, como leer y escribir a si misma en el disco, como convertirse a si misma desde y hacia XML y como imprimirse en varios formatos de informes. Puedes oler la fragibilidad? Cambia de SAX a DOM y deberas cambiar Venta, cambia de guardar a un archivo a guardar en una base de datos y tendras que cambiar Venta. Cambia el formato de los informes y tendras que cambiar Venta, te das cuenta a lo que quiero llegar, cuantas razones hay para cambiar la clase Venta? Si, existen 3 razones para cambiar nuestra clase, esto viola completamente el principio de la unica responsabilidad. Este diseno esta malamente acoplado.

El objetivo es separar todos estos conceptos en sus propias clases de forma que cada clase tenga una y solo una razon para cambiar. Nos gustaria que la clase Venta tratara de calculaTotal y calculaImpuestos que una clase XML relacionada tratara con la conversion de instancias de Venta desde y hacia XML, que una clase GuardarVenta tratara con la lectura y escritura de Venta al disco duro y que hubiera una clase para visualizar los informes. En resumen queremos separar cada tarea .

A continuacion muestro un diagrama de como pudiera quedar el conjunto de las nuevas clases.











sábado, 20 de agosto de 2011

Calidad en el Diseño

Que significa que un sistema este bien diseñado? Un sistema esta bien diseñado si es fácil de comprender, fácil de cambiar y fácil de reutilizar. No presenta dificultades concretas de desarrollo es simple terso y económico. Es un placer trabajar con el. A la inversa, un mal diseño no dan ganas de trabajar con el.

Personalmente cuido las siguientes caracteristicas:

Rigidez: El sistema es dificil de cambiar porque cada vez que cambias algo este cambio afecta a otra parte del sistema y entonces nuevamente tienes que cambiar y luego este cambio afecta otra parte del sistema... asi se vuelve un cambio interminable.

Fragilidad: Un cambio en una parte del sistema provoca una ruptura en muchas otras partes que no tienen nada que ver.

Inmovilidad: Se hace muy dificil descomponer el sistema en partes que puedan ser reusables en otros sistemas.

Viscosidad: El entorno de desarrollo se sostiene con cinta adhesiva y engrudo. Lleva una eternidad pasar por el bucle editar-compilar-probar.

Repetición innecesaria El código tiene todo el aspecto de haber sido escrito por dos programadores llamados Copia y Pega, personalmente me llevo cerca de un año dejar este mal habito.

Opacidad: Resulta dificil aclarar cuales fueron las intenciones del creador debido a las formas rebuscadas de expresion.

En las siguientes entradas escribiré tips para evitar caer en estos malos hábitos.

Hello World

Tengo que admitirlo, mantener al día este blog supondrá un esfuerzo adicional para mi. Es complicado escribir, aunque no lo creas, ademas tengo un chingo de cosas por hacer. Aun así, poder expresar lo que siento es algo muy importante para mi.
Espero poder usar este espacio para compartir con ustedes mis pensamientos y conocimiento, más importante aun, espero recibir retro alimentación. Así que siéntete libre de comentar todos mis post.

I have to recognize keeping a blog updated will be a very important effort to me. It's complicated to write for me and I have a ton of things on my to do list. However, I thing spreading the word is an important  task for me.
I hope I can use this space to share my thoughts with you and, most importantly, be able to get your beedback firsthand. Please, feel free to comment my posts.
Anyway, here we go. Let's see what happens.