Evitando la Obsesión por Primitivas en resources de Angular

Uno de los problemas que encontré mientras trabajaba en una aplicación legada hecha en Angular el año pasado, fue encontrar resources que correspondían a estructuras de datos con varios niveles de anidación a los que se accedía directamente desde muchas partes del código. Se estaba exponiendo demasiado la estructura interna de los resources lo cual hacía que el código encargado de interactuar con los resources estuviera esparcido por todas partes originando muchísima duplicación. Esto provocaba que el código fuera muy difícil de entender y cambiar. El código sufría un caso grave de Obsesión por Primitivas, debido al acceso directo indiscriminado a la estructura interna de los resources. Para prevenir este problema en la nueva aplicación Angular que estamos haciendo actualmente, estamos aplicando la técnica de añadir comportamiento a los resources mediante la función extend de Underscore. De este modo, hemos conseguido ocultarle su estructura interna al código que los usa y, al mismo tiempo, hemos creado nuevos objetos que han "atraido" el comportamiento encargado de tratar con los resources que en la otra aplicación se encontraba esparcido por todo el código. Esta estrategia nos ha colocado en una situación mucho mejor, ya que ahora, si la estructura de los datos JSON de un resource cambia por el motivo que sea, sólo existe un punto al que ir para adaptar el código a dicho cambio. Además la legibilidad del código ha mejorado al poder dar nombres significativos a las diferentes operaciones sobre los resources. Este es un ejemplo de uno de los resources que se encuentran en nuestro código: [gist id="918ad97f7c721ef6139b"] Fíjate cómo se está usando la función extend para añadir el comportamiento definido en TrackMethods al prototype del resource Track. TrackMethods es un objeto que contiene varias funciones que sirven para ocultar la estructura interna de Track y al mismo tiempo comunicar mejor la intención de lo que se hace con él: [gist id="90a3ce8cafe70987b3d6"] La única restricción que nos ponemos a la hora de crear estas extensiones de comportamiento es que sólo pueden incluir funciones, es decir, no pueden tener nada de estado. Actualmente TrackMethods sólo contiene unos pocos accessors, pero seguramente crecerá según la aplicación vaya evolucionando. Hay que decir que todas las funciones de TrackMethods fueron "descubiertas" en otras partes del código y movidas a TrackMethods mediante refactoring. Siempre intentamos estar alerta para descubrir nuevas oportunidades de mover código hacia estas extensiones de comportamiento o crearlo directamente en ellas. Otra ventaja que hemos encontrado utlizando esta técnica es que estas extensiones de comportamiento se pueden testear muy fácilmente usando fake resources. Actualmente estos son los tests de TrackMethods: [gist id="4aa7c493265960dfb660"] La estrategia de extender los resources de Angular con comportamiento es una alternativa a encapsular colecciones que nos está funcionando bastante bien para prevenir problemas derivados de la Obsesión por Primitivas. La versión original de este post se encuentra en garajeando.blogspot.com.es.