Muchas veces cuando nos iniciamos en el desarrollo queremos abarcarlo enfocándonos en el resultado a obtener, sin importar muchas veces la forma ni el fondo. En SharePoint, por la forma en la que extendemos su funcionamiento fuera de la caja (OOTB), tenemos a introducir en un WebPart todo lo necesario para cumplir el objetivo. Dentro de este WebPart está claro que tendremos que incluir los siguientes componentes:

• Código Behind
• Ficheros de diseño (CSS, imágenes,…)
• JavaScript
• Definición de Listas, Tipos de Contenido, PageLayouts, MasterPages.

Pero muchas veces adoptamos decisiones sin pensar en cada elemento que desarrollamos y unificamos todos estos elementos en un TODO. Esto hace que nuestros desarrollos desplegados en otro entorno, dejen de funcionar. Otras veces, desarrollamos tratando cada elemento por separado y lo que ocurre (en el mejor de los casos) es que duplicamos la carga de ficheros y, en el resto de ocasiones, que tengamos problemas entre los propios WebParts. Muchas veces hay WebPart que se solapan estilos, que se reemplazan desarrollos de JavaScript. ¿Por qué no aplicamos patrones que sabemos su certeza?

¿Qué es el principio de responsabilidad?

El Principio de Responsabilidad Única o Single Responsability Principle está basado en el Principio de Cohesión y describe el nivel de acoplamiento ordinal entre módulos dentro de la ingeniería del Software.

Una clase debe tener una y sólo una única causa por la cual puede ser modificada

Si una clase/fichero/artefacto tiene dos responsabilidades entonces asume dos motivos por los cuales puede ser modificada. Ahora bien, este principio de responsabilidad para facilitarnos el mantenimiento del mismo lo que significa es que cada elemento solamente realiza una única cosa y que esta cosa la hace bien.

Caso de estudio

Partamos del supuesto en el que tenemos dos WebPart que vamos a utilizar dentro de nuestro desarrollo:

1. WebPart Calendario: En la que se consulta las reuniones que tiene el visitante en curso. Para ello, se utiliza un plugin de Jquery para renderizar estos valores.
2. WebPart Social: En el que realizamos consultas a la API de Yammer y la integramos dentro de un sitio de departamentos.

¿Cuál es el problema?

El WebPart de Calendario utiliza una referencia a Jquery antes de cargar el Plugin del Calendario. El WebPart Social utiliza Jquery para realizar diversas modificaciones en el DOM. Ahora bien, el principal problema que tenemos si en ambos WebPart añadimos una referencia a Jquery, es que sino se controla el orden de la carga de las librerías puede ocurrir que (en caso de que la referencia del calendario se cargue antes que el WebPart Social) no podamos utilizar el plugin anteriormente mencionado. Con lo cual se produce un funcionamiento no deseado en nuestra aplicación.

¿Cómo podemos solucionarlo?

El uso de JavaScript incrustado entre otra funcionalidad hace que en ocasiones cumplir el principio de responsabilidad sea una tarea no trivial. Ahora bien, siempre que se adopta una buena solución es posible y es necesario. Soluciones hay muchas:

1. Agregar las referencias que puedan ser comunes dentro de la master. En la master indicaremos aquellas librerías que utilizamos en todas las páginas y de esta forma evitamos tener el problema.
2. Agregar la carga de los scripts bajo demanda, de tal forma que si una librería/referencia ya esta cargada no la volvamos a cargar.
3. Plantearnos realmente si el utilizar esta librera es necesario o no. Muchas veces añadimos una referencia a Jquery cuando realmente utilizando JavaScript  «puro» sería suficiente.  Lee este post realmente interesante sobre esta opinión

¿Por qué utilizar el Principio de Responsabilidad Única?

Dentro del ciclo de desarrollo de aplicaciones software, no tenemos en cuenta que este proceso no termina cuando ponemos la aplicación en Producción, sino que la aplicación evoluciona  y se modifica una vez ya esta en producción. Este proceso de mantenimiento no se suele tener en cuenta y durante esta fase del ALM es cuando nos damos cuenta de que hemos realizado un código difícil de mantener y muy costoso. Este es el momento en el que lamentamos  no haber solucionado un problema que en ese momento si que tenia solución.

Conclusión

Muchas veces a la hora del desarrollo software nos saltamos alguna fase por diversos motivos: tiempo, desconocimiento… pero tenemos que ser conscientes de que alguna de estas decisiones las podemos sufrir en un futuro.  Si hacemos un código difícilmente mantenible, en algún momento tendremos que abordar su modificación y en ese momento es cuando nos arrepentiremos del camino escogido. Como comento en reiteradas ocasiones, hacer el desarrollo bien no cuesta más que hacerlo mal sino que hay que pensar.

Referencias:

http://josemigueltorres.net/index.php/principio-de-responsabilidad-unica/