Un'introduzione a CDI (Contexts and Dependency Injection) in Java

1. Panoramica

CDI (Contexts and Dependency Injection) è un framework standard di inserimento delle dipendenze incluso in Java EE 6 e versioni successive.

Ci consente di gestire il ciclo di vita dei componenti con stato tramite contesti del ciclo di vita specifici del dominio e di inserire componenti (servizi) negli oggetti client in modo indipendente dai tipi.

In questo tutorial, daremo uno sguardo approfondito alle funzionalità più rilevanti di CDI e implementeremo diversi approcci per l'inserimento di dipendenze nelle classi client.

2. DYDI (iniezione di dipendenza fai-da-te)

In poche parole, è possibile implementare DI senza ricorrere a nessun framework.

Questo approccio è comunemente noto come DYDI (Do-it-Yourself Dependency Injection).

Con DYDI, manteniamo il codice dell'applicazione isolato dalla creazione di oggetti passando le dipendenze richieste nelle classi client attraverso semplici vecchie fabbriche / costruttori.

Ecco come potrebbe apparire un'implementazione DYDI di 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(); } }

Naturalmente, DYDI è adatto per alcuni casi d'uso relativamente semplici.

Se la nostra applicazione di esempio aumentasse di dimensioni e complessità, implementando una rete più ampia di oggetti interconnessi, finiremmo per inquinarla con tonnellate di fabbriche di grafi a oggetti.

Ciò richiederebbe molto codice boilerplate solo per la creazione di grafici a oggetti. Questa non è una soluzione completamente scalabile.

Possiamo fare di meglio? Certo che possiamo. Ecco esattamente dove entra in gioco CDI.

3. Un semplice esempio

CDI trasforma DI in un processo semplicissimo, ridotto alla semplice decorazione delle classi di servizio con poche semplici annotazioni e alla definizione dei punti di iniezione corrispondenti nelle classi client.

Per mostrare come CDI implementa DI al livello più elementare, supponiamo di voler sviluppare una semplice applicazione per l'editing di file immagine. Capace di aprire, modificare, scrivere, salvare un file immagine e così via.

3.1. Il “beans.xml” File

Per prima cosa, dobbiamo inserire un file "bean.xml" nella cartella "src / main / resources / META-INF /" . Anche se questo file non contiene alcuna direttiva DI specifica, è necessario per far funzionare CDI :

3.2. Le classi di servizio

Successivamente, creiamo le classi di servizio che eseguono le operazioni sopra menzionate sui file GIF, JPG e 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

Infine, implementiamo una classe client che accetta un'implementazione ImageFileEditor nel costruttore e definiamo un punto di iniezione con l' annotazione @Inject :

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

In poche parole, l' annotazione @Inject è il vero cavallo di battaglia di CDI. Ci permette di definire i punti di iniezione nelle classi client.

In questo caso, @Inject indica a CDI di iniettare un'implementazione ImageFileEditor nel costruttore.

Inoltre, è anche possibile iniettare un servizio utilizzando l' annotazione @Inject nei campi (field injection) e setter (setter injection). Esamineremo queste opzioni più avanti.

3.4. Creazione del grafico dell'oggetto ImageFileProcessor con Weld

Ovviamente, dobbiamo assicurarci che CDI inietti la corretta implementazione ImageFileEditor nel costruttore della classe ImageFileProcessor .

Per fare ciò, in primo luogo, dovremmo ottenere un'istanza della classe.

Poiché non faremo affidamento su alcun server delle applicazioni Java EE per l'utilizzo di CDI, lo faremo con Weld, l'implementazione di riferimento CDI in 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(); } 

Qui stiamo creando un oggetto WeldContainer , quindi otteniamo un oggetto ImageFileProcessor e infine chiamiamo il suo metodo openFile () .

Come previsto, se eseguiamo l'applicazione, CDI si lamenterà ad alta voce lanciando un'eccezione DeploymentException:

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

Stiamo ottenendo questa eccezione perché CDI non sa quale implementazione ImageFileEditor iniettare nel costruttore ImageFileProcessor .

Nella terminologia CDI , ciò è noto come eccezione di injection ambigua .

3.5. Le annotazioni @Default e @Alternative

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

Indiscutibilmente, CDI rende l'inserimento delle dipendenze un gioco da ragazzi , il costo delle annotazioni extra è uno sforzo minimo per il guadagno dell'iniezione di dipendenze organizzata.

Ci sono momenti in cui DYDI ha ancora il suo posto su CDI. Come quando si sviluppano applicazioni abbastanza semplici che contengono solo semplici grafici a oggetti.

Come sempre, tutti gli esempi di codice mostrati in questo articolo sono disponibili su GitHub.