Une introduction à CDI (Contexts and Dependency Injection) en Java

1. Vue d'ensemble

CDI (Contexts and Dependency Injection) est un framework d'injection de dépendances standard inclus dans Java EE 6 et supérieur.

Il nous permet de gérer le cycle de vie des composants avec état via des contextes de cycle de vie spécifiques au domaine et d'injecter des composants (services) dans des objets client de manière sécurisée.

Dans ce didacticiel, nous examinerons en profondeur les fonctionnalités les plus pertinentes de CDI et implémenterons différentes approches pour l'injection de dépendances dans les classes clientes.

2. DYDI (injection de dépendance à faire soi-même)

En un mot, il est possible d'implémenter DI sans recourir à aucun framework.

Cette approche est connue sous le nom de DYDI (Do-it-Yourself Dependency Injection).

Avec DYDI, nous gardons le code d'application isolé de la création d'objet en passant les dépendances requises dans les classes clientes via d'anciennes usines / constructeurs.

Voici à quoi pourrait ressembler une implémentation DYDI de base:

public interface TextService { String doSomethingWithText(String text); String doSomethingElseWithText(String text); }
public class SpecializedTextService implements TextService { ... }
public class TextClass { private TextService textService; // constructor }
public class TextClassFactory { public TextClass getTextClass() { return new TextClass(new SpecializedTextService(); } }

Bien entendu, DYDI convient à certains cas d'utilisation relativement simples.

Si notre exemple d'application augmentait en taille et en complexité, implémentant un plus grand réseau d'objets interconnectés, nous finirions par le polluer avec des tonnes d'usines de graphes d'objets.

Cela nécessiterait beaucoup de code standard juste pour créer des graphiques d'objets. Ce n'est pas une solution entièrement évolutive.

Pouvons-nous faire mieux la DI? Bien sûr on peut. Voici exactement où CDI entre en jeu.

3. Un exemple simple

CDI transforme la DI en un processus simple, se résumant à simplement décorer les classes de service avec quelques annotations simples et à définir les points d'injection correspondants dans les classes clientes.

Pour montrer comment CDI implémente DI au niveau le plus basique, supposons que nous souhaitons développer une application d'édition de fichier image simple. Capable d'ouvrir, éditer, écrire, enregistrer un fichier image et ainsi de suite.

3.1. Le fichier «beans.xml»

Tout d'abord, nous devons placer un fichier «beans.xml» dans le dossier «src / main / resources / META-INF /» . Même si ce fichier ne contient pas du tout de directives DI spécifiques, il est nécessaire pour que CDI soit opérationnel :

3.2. Les classes de service

Ensuite, créons les classes de service qui effectuent les opérations sur les fichiers mentionnés ci-dessus sur les fichiers GIF, JPG et PNG:

public interface ImageFileEditor { String openFile(String fileName); String editFile(String fileName); String writeFile(String fileName); String saveFile(String fileName); }
public class GifFileEditor implements ImageFileEditor { @Override public String openFile(String fileName) { return "Opening GIF file " + fileName; } @Override public String editFile(String fileName) { return "Editing GIF file " + fileName; } @Override public String writeFile(String fileName) { return "Writing GIF file " + fileName; } @Override public String saveFile(String fileName) { return "Saving GIF file " + fileName; } }
public class JpgFileEditor implements ImageFileEditor { // JPG-specific implementations for openFile() / editFile() / writeFile() / saveFile() ... }
public class PngFileEditor implements ImageFileEditor { // PNG-specific implementations for openFile() / editFile() / writeFile() / saveFile() ... }

3.3. La classe client

Enfin, implémentons une classe client qui prend une implémentation ImageFileEditor dans le constructeur, et définissons un point d'injection avec l' annotation @Inject :

public class ImageFileProcessor { private ImageFileEditor imageFileEditor; @Inject public ImageFileProcessor(ImageFileEditor imageFileEditor) { this.imageFileEditor = imageFileEditor; } }

En termes simples, l' annotation @Inject est la véritable bête de somme de CDI. Cela nous permet de définir des points d'injection dans les classes clientes.

Dans ce cas, @Inject demande à CDI d'injecter une implémentation ImageFileEditor dans le constructeur.

De plus, il est également possible d'injecter un service en utilisant l' annotation @Inject dans les champs (injection de champ) et les setters (injection de setter). Nous examinerons ces options plus tard.

3.4. Création du graphe d' objets ImageFileProcessor avec Weld

Bien sûr, nous devons nous assurer que CDI injectera la bonne implémentation ImageFileEditor dans le constructeur de classe ImageFileProcessor .

Pour ce faire, nous devons d'abord obtenir une instance de la classe.

Comme nous ne dépendons d'aucun serveur d'applications Java EE pour utiliser CDI, nous le ferons avec Weld, l'implémentation de référence CDI dans Java SE :

public static void main(String[] args) { Weld weld = new Weld(); WeldContainer container = weld.initialize(); ImageFileProcessor imageFileProcessor = container.select(ImageFileProcessor.class).get(); System.out.println(imageFileProcessor.openFile("file1.png")); container.shutdown(); } 

Ici, nous créons un objet WeldContainer , puis obtenons un objet ImageFileProcessor , et enfin appelons sa méthode openFile () .

Comme prévu, si nous exécutons l'application, CDI se plaindra bruyamment en lançant une DeploymentException:

Unsatisfied dependencies for type ImageFileEditor with qualifiers @Default at injection point...

Nous obtenons cette exception car CDI ne sait pas quelle implémentation ImageFileEditor injecter dans le constructeur ImageFileProcessor .

Dans la terminologie CDI , cela est connu comme une exception d'injection ambiguë .

3.5. Les @default et @Alternative Annotations

Solving this ambiguity is easy. CDI, by default, annotates all the implementations of an interface with the @Default annotation.

So, we should explicitly tell it which implementation should be injected into the client class:

@Alternative public class GifFileEditor implements ImageFileEditor { ... }
@Alternative public class JpgFileEditor implements ImageFileEditor { ... } 
public class PngFileEditor implements ImageFileEditor { ... }

In this case, we've annotated GifFileEditor and JpgFileEditor with the @Alternative annotation, so CDI now knows that PngFileEditor (annotated by default with the @Default annotation) is the implementation that we want to inject.

If we rerun the application, this time it'll be executed as expected:

Opening PNG file file1.png 

Furthermore, annotating PngFileEditor with the @Default annotation and keeping the other implementations as alternatives will produce the same above result.

This shows, in a nutshell, how we can very easily swap the run-time injection of implementations by simply switching the @Alternative annotations in the service classes.

4. Field Injection

CDI supports both field and setter injection out of the box.

Here's how to perform field injection (the rules for qualifying services with the @Default and @Alternative annotations remain the same):

@Inject private final ImageFileEditor imageFileEditor;

5. Setter Injection

Similarly, here's how to do setter injection:

@Inject public void setImageFileEditor(ImageFileEditor imageFileEditor) { ... }

6. The @Named Annotation

So far, we've learned how to define injection points in client classes and inject services with the @Inject, @Default , and @Alternative annotations, which cover most of the use cases.

Nevertheless, CDI also allows us to perform service injection with the @Named annotation.

This method provides a more semantic way of injecting services, by binding a meaningful name to an implementation:

@Named("GifFileEditor") public class GifFileEditor implements ImageFileEditor { ... } @Named("JpgFileEditor") public class JpgFileEditor implements ImageFileEditor { ... } @Named("PngFileEditor") public class PngFileEditor implements ImageFileEditor { ... }

Now, we should refactor the injection point in the ImageFileProcessor class to match a named implementation:

@Inject public ImageFileProcessor(@Named("PngFileEditor") ImageFileEditor imageFileEditor) { ... }

It's also possible to perform field and setter injection with named implementations, which looks very similar to using the @Default and @Alternative annotations:

@Inject private final @Named("PngFileEditor") ImageFileEditor imageFileEditor; @Inject public void setImageFileEditor(@Named("PngFileEditor") ImageFileEditor imageFileEditor) { ... }

7. The @Produces Annotation

Sometimes, a service requires some configuration to be fully-initialized before it gets injected to handle additional dependencies.

CDI provides support for these situations, through the @Produces annotation.

@Produces allows us to implement factory classes, whose responsibility is the creation of fully-initialized services.

To understand how the @Produces annotation works, let's refactor the ImageFileProcessor class, so it can take an additional TimeLogger service in the constructor.

The service will be used for logging the time at which a certain image file operation is performed:

@Inject public ImageFileProcessor(ImageFileEditor imageFileEditor, TimeLogger timeLogger) { ... } public String openFile(String fileName) { return imageFileEditor.openFile(fileName) + " at: " + timeLogger.getTime(); } // additional image file methods 

In this case, the TimeLogger class takes two additional services, SimpleDateFormat and Calendar:

public class TimeLogger { private SimpleDateFormat dateFormat; private Calendar calendar; // constructors public String getTime() { return dateFormat.format(calendar.getTime()); } }

How do we tell CDI where to look at for getting a fully-initialized TimeLogger object?

We just create a TimeLogger factory class and annotate its factory method with the @Produces annotation:

public class TimeLoggerFactory { @Produces public TimeLogger getTimeLogger() { return new TimeLogger(new SimpleDateFormat("HH:mm"), Calendar.getInstance()); } }

Whenever we get an ImageFileProcessor instance, CDI will scan the TimeLoggerFactory class, then call the getTimeLogger() method (as it's annotated with the @Produces annotation), and finally inject the Time Logger service.

If we run the refactored sample application with Weld, it'll output the following:

Opening PNG file file1.png at: 17:46

8. Custom Qualifiers

CDI supports the use of custom qualifiers for qualifying dependencies and solving ambiguous injection points.

Custom qualifiers are a very powerful feature. They not only bind a semantic name to a service, but they bind injection metadata too. Metadata such as the RetentionPolicy and the legal annotation targets (ElementType).

Let's see how to use custom qualifiers in our application:

@Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.METHOD, ElementType.TYPE, ElementType.PARAMETER}) public @interface GifFileEditorQualifier {} 
@Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.METHOD, ElementType.TYPE, ElementType.PARAMETER}) public @interface JpgFileEditorQualifier {} 
@Qualifier @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.METHOD, ElementType.TYPE, ElementType.PARAMETER}) public @interface PngFileEditorQualifier {} 

Now, let's bind the custom qualifiers to the ImageFileEditor implementations:

@GifFileEditorQualifier public class GifFileEditor implements ImageFileEditor { ... } 
@JpgFileEditorQualifier public class JpgFileEditor implements ImageFileEditor { ... }
@PngFileEditorQualifier public class PngFileEditor implements ImageFileEditor { ... } 

Lastly, let's refactor the injection point in the ImageFileProcessor class:

@Inject public ImageFileProcessor(@PngFileEditorQualifier ImageFileEditor imageFileEditor, TimeLogger timeLogger) { ... } 

If we run our application once again, it should generate the same output shown above.

Custom qualifiers provide a neat semantic approach for binding names and annotation metadata to implementations.

In addition, custom qualifiers allow us to define more restrictive type-safe injection points (outperforming the functionality of the @Default and @Alternative annotations).

If only a subtype is qualified in a type hierarchy, then CDI will only inject the subtype, not the base type.

9. Conclusion

Incontestablement, CDI fait de l'injection de dépendances une évidence , le coût des annotations supplémentaires est très peu d'effort pour le gain de l'injection de dépendances organisée.

Il y a des moments où DYDI a encore sa place sur CDI. Comme lors du développement d'applications assez simples qui ne contiennent que de simples graphiques d'objets.

Comme toujours, tous les exemples de code présentés dans cet article sont disponibles à l'adresse over sur GitHub.