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.











No hay comentarios:

Publicar un comentario