Inversion de dépendances (1)

Le problème

Supposons l’architecture suivante où la classe A dépend de la classe B.

Dans cette conception, si B est amenée à changer (e.g. montée en version), alors la classe B et la classe A vont devoir être rédéployées. On va devoir :

• packager B et A
• build B et A
• pour finalement déployer B et A chez le client

Or, seulement B a été modifiée. Nous souhaitons donc que seulement B soit packagée, build et déployée chez le client.

Inversion de dépendance

Pour ce faire, nous allons utiliser le principe d’Inversion de dépendances.

Note

• Les modules de haut niveau (e.g. A) ne doivent pas dépendre des modules de bas niveau (e.g. B).
• Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.

En d’autre terme, A qui est un détail doit dépendre d’une interface I.

Si nous appliquons ces deux affirmations à notre architecture nous obtenons

• A ne dépend plus de B mais de son interface IB
• Donc si B est modifiée alors seulement B sera packagée, build et déployée chez le client

Note

Cependant, si nous modifions l’interface IB alors les classes B et A devront être packagées, build et déployées chez le client. Néanmoins une interface est moins volatile qu’une implémentation.