Deux autres principes peu connus pour l’injection de dépendance

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.

Print | posted on Friday, July 6, 2018 12:36 AM

Feedback

No comments posted yet.

Your comment:





 
Please add 2 and 7 and type the answer here:

Copyright © Frédéric Decréquy

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski