Deux autres principes peu
connus pour l’injection de dépendance
L’injection de dépendance veut rendre indépendant
les classes choisies de leur référencement. Il faut d’abord les redéfinir sous
forme d’interface. Puis cela consiste généralement à avoir un générateur à
inférence d’objet, qui, suivant un code qui de description des liaisons
références-inférences dans la couche la plus basse, transforme les interfaces
référencées en un équivalent concret, sous forme d’objets, de singletons ou de
classes. L’outil préconisé par Microsoft est Unity.
A ce que je sache, le design pattern de fabrique
abstraite a aussi cette fonction. Je l’utilise en le créant dans chaque couche
de mon application, où seule la dernière classe héritée, dans la couche la plus
basse, n’est pas abstraite. Les interfaces existent toujours, mais ici on peut
aussi partir du type hérité, ou de composants-sous-fabriques abstraites. Les
interfaces, comme les classes héritées abstraites, comme les
composants-sous-fabriques abstraites voient leurs concrétisations vendues dans
un membre virtuel de leur couche correspondante, un héritage en cascade de la
classe la plus haute de cette fabrique abstraite. A chaque niveau d’héritage de
la fabrique abstraite principale, un membre RootInstance est défini et retypé.
On peut travailler avec un singleton, mais il est intéressant de se servir aussi
de cette fabrique abstraite, que j’hésite à nommer Space, Context,
AbstractFactory ou FactoryAndContext, pour stocker aussi les variables de
contexte de l’application et les membres de la classe redirectrice habituelle
ServiceLocator. Il est intéressant parfois de ne pas s’en servir comme d’un
singleton et de le passer en paramètre aux principaux constructeurs.
Une injection d’inférences par générateur
d’inférence à partir de références a l’avantage non encore implémenté dans Unity
par rapport à la fabrique abstraite de pouvoir désérialiser des interfaces sans
connaissance de l’objet final. La fabrique abstraite a l’avantage de suivre la
structure de l’application, de ne pas considérer les classes comme des numéros,
de pouvoir inférencer à partir de classes héritées, donc avec un cœur, et de
pouvoir conditionner les inférences de façon propre et localisée.
Une forme à suivre d’injection de dépendance est
le DataTemplate du XAML, qui permet d’envoyer directement dans les contrôles des
blocs en provenance des classes de viewmodels, et on se sert du DataTemplate
pour définir, potentiellement en cascade, les contrôles utilisateur WPF à
inférer en lieu et place concrète. Ce qui permet de laisser la logique faire
découler toute seule le choix de l’objet WPF à utiliser en fonction des choix du
viewmodel, sans switch ni code ni dépendance en dur.