En este capítulo se expone la
relación entre los componentes. De nuevo hay una tensión entre la capacidad de
desarrollo y la lógica de diseño.
El principio de dependencias acíclicas
Es común que, en los equipos de desarrollo formados por varios programadores, un miembro
del equipo desarrolle algo para encontrarse al día siguiente que su desarrollo
ha dejado de funcionar debido a que otro miembro del equipo ha modificado algo
de lo que dependía.
Para resolver estos problemas se pueden adoptar dos estrategias:
· Construcción semanal.
· Acyclic Dependencies Principle.
Construcción semanal
Esta estrategia consiste en que los desarrolladores se aíslan de los cambios del
resto durante cuatro días y, el viernes, hacer la integración de los cambios y
la construcción de la «release».
A medida que el proyecto crece, es posible que el día de la integración no sea
suficiente y haya que ampliar el tiempo a más de un día. Y, si el proyecto
sigue creciendo, el tiempo de integración irá aumentado llevando el proyecto a
un escenario poco deseable.
Eliminando los ciclos de dependencia
La solución a este problema es dividir el sistema en componentes y que se puedan crear
nuevas versiones de estos de manera independiente. Cuando se crea una nueva
versión del componente se le asocia un número de versión y el resto de
desarrolladores pueden utilizar esta nueva versión o continuar con la antigua.
Cada desarrollador puede decidir cuándo adaptar esta nueva versión del
componente.
En este caso, la integración se produce en pequeños incrementos y no hay un punto
concreto donde todos los desarrolladores integran todo.
Para que esta estrategia funcione la estructura de dependencias de los componentes no
puede tener ciclos. En el caso de haber ciclos no se evitaría el problema de
que un desarrollador se encuentre al día siguiente con algo que no funcione.
Considere el siguiente diagrama de componentes que muestra los distintos componentes de
una aplicación y las dependencias que hay entre ellos. La dirección de las
flechas marca la dependencia de un componente con otro.
Se puede apreciar como siguiendo las dependencias desde cualquier componente es
imposible volver a ese mismo componente. Esta estructura no tiene ciclos. Esto
es un Gráfico Acíclico Dirigido o «Directed Acyclic Graph» (DAG).
Es fácil encontrar qué componentes son afectados por una nueva versión. En el caso de
haber una nueva versión del componente «Models» los componentes «Database» y
«Main» se verían afectados y los responsables de estos módulos deberían
integrar la nueva versión de «Models» cuando estimen oportuno.
También se puede apreciar que cuando el componente «Main» tiene una nueva versión y se
despliega no tiene ningún efecto en el resto de componentes.
Cuando se quiera desplegar el sistema entero se tendría que proceder de los componentes
de la parte inferior del diagrama a la parte superior. Esto es compilar,
testear y desplegar los componentes «Entities» y «Services». Seguidos por los
componentes «Controllers», «Models», «Vistas». El siguiente sería «Database»
mientras que «Main» sería el último.
El sistema es fácil de desplegar ya que se puede entender las dependencias entre las
distintas partes
El efecto de un ciclo en el gráfico de dependencias de componentes
En el caso de tener un requerimiento y una de las clases de «Entities» termina usando una
de las clases de «Models» creando así un ciclo de dependencia.
Debido al ciclo «Database» es más difícil de desplegar ya que depende de «Models» y este
tiene una dependencia con «Entities» por lo que «Models» y «Entities» es como
si se convirtiera en un módulo.
A la hora de testear los componentes se complica ya que hay que construir e integrar las
dependencias con «Models» y «Entities».
Rompiendo el ciclo
Siempre es posible romper un ciclo y volver a un «DAG». Hay dos estrategias:
1.- Utilizar el Dependency Inversion Principle (DIP).
Con esta estrategia se crea una interfaz con los métodos que la clase de «Models»
necesite. Esta interfaz estaría en «Models» y heredaría de la clase de
«Entities». Esto invierte la dependencia entre «Models» y «Entities» de manera
que rompe el ciclo.
2.- Extraer la funcionalidad en un nuevo componente y que tanto «Models» como «Entities»
dependan de este nuevo componente. En este caso se crea un nuevo componente
«Permissions».
Miedos
La estrategia de crear nuevos componentes da paso a una estructura volátil que
cambia con el tiempo. Por esta razón siempre se debe estar atentos a descubrir
los ciclos que puedan ocurrir y romperlos.
No hay comentarios:
Publicar un comentario