A l’aide d’une analyse statique de notre projet avec NDepend, nous remarquons que notre projet contient une dépendance cyclique de namespace.

Cette dépendance est identifiée dans notre assembly whohive.

En utilisant la vue Dependency Matrix de NDepend on visualise rapidement cette dépendance à l’aide des carrés noirs.

La dépendance qui nous concerne dans ce cas est entre les namespaces whohive.Controllers et whohive.Controllers.Validation.

En cherchant plus en profondeur, on voit que les deux classes impliquées dans cette dépendance sont JobPostController et JobPostControllerValidation.

Maintenant que nous avons identifié l’endroit dans nos classes nous allons pouvoir nous pencher un peu plus sur le code.

En y regardant de plus prêt nous voyons que JobPostControllerValidation est une classe d’extension de la classe JobPostController avec deux méthodes d’extensions. Elle est donc statique.

Si nous recherchons à l’aide de Resharper (ALT-F7) l’utilisation de cette méthode nous trouvons qu’elle est utilisée une seule fois par ApplyPost, de la classe JobPostController.

Ce que nous aurions pu voir aussi à l’aide de NDepend.

Le but de notre refactoring est de découpler ces deux classes afin de rompre le cycle de dépendance et de permettre une injection par le constructeur de la classe JobPostController. Cette injection sera faite à l’aide d’une interface IJobPostValidator.

Lorsque la classe JobPostController sera construite, à l’aide d’une injection de l’interface IJobPostValidator, elle sera de suite testable. Car en premier lieu elle n’aura plus la responsabilité de créer une de ses dépendances, mais cette dépendance lui sera injectée par son constructeur. Enfin la dépendance qu’elle avait avant envers la classe ; JobPostControllerValidation, est transformée en une dépendance envers une interface, IJobPostValidator. Comme il s’agit d’une interface nous pourrons en faire un mock ou un stub et donc tester JobPostController en isolation.