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.