Konstruktørinjektion om foråret med Lombok

1. Introduktion

Lombok er et yderst nyttigt bibliotek, der overvinder kedelpladekoden. Hvis du ikke er bekendt med det endnu, anbefaler jeg stærkt at kigge på den foregående tutorial - Introduktion til Project Lombok.

I denne artikel demonstrerer vi dets anvendelighed, når de kombineres med Spring's Konstruktørbaseret afhængighedsinjektion.

2. Konstruktørbaseret afhængighedsinjektion

En god måde at overføre afhængigheder om foråret ved hjælp af cinstruktørbaseret afhængighedsinjektion. Denne tilgang tvinger os til eksplicit at overføre komponentens afhængigheder til en konstruktør.

I modsætning til Feltbaseret afhængighedsinjektion, det giver også en række fordele:

intet behov for at oprette en testspecifik konfigurationskomponent - afhængigheder injiceres eksplicit i en konstruktør
konsistent design - alle krævede afhængigheder fremhæves og passes af konstruktørens definition
enkle enhedstest - reduceret Spring Framework's overhead
genvundet brugsfrihed endelig nøgleord

På grund af behovet for at skrive en konstruktør bruger det imidlertid til at føre til en betydeligt større kodebase. Overvej de to eksempler på HilsenService og FarvelService:

@Komponent offentlig klasse GreetingService {@Autowired privat oversætteroversætter; public String produce () {return translator.translate ("hej"); }}

@Komponent offentlig klasse FarewellService {privat endelig Oversætteroversætter; public FarewellService (Oversætteroversætter) {this.translator = oversætter; } public String produce () {return translator.translate ("farvel"); }}

Dybest set gør begge komponenter det samme - de kalder en konfigurerbar Oversætter med et opgave-specifikt ord.

Den anden variation er dog meget mere tilsløret på grund af konstruktørens kedelplade, som ikke rigtig bringer nogen værdi til koden.

I den nyeste Spring-udgivelse behøver konstruktøren ikke at blive kommenteret @Autowired kommentar.

3. Konstruktørinjektion med Lombok

Med Lombok, er det muligt at generere en konstruktør til enten alle klassens felter (med @AllArgsConstructor) eller alle endelig klassens felter (med @RequiredArgsConstructor). Desuden, hvis du stadig har brug for en tom konstruktør, kan du tilføje en ekstra @NoArgsConstructor kommentar.

Lad os oprette en tredje komponent, analog med de to foregående:

@Komponent @RequiredArgsConstructor offentlig klasse ThankingService {privat endelig Oversætter oversætter; public String produce () {return translator.translate ("tak"); }}

Ovenstående kommentar vil forårsage Lombok at generere en konstruktør til os:

@Komponent offentlig klasse ThankingService {privat endelig Oversætter oversætter; offentlig streng tak () {return translator.translate ("tak"); } / * Genereret af Lombok * / public ThankingService (oversætteroversætter) {this.translator = oversætter; }}

4. Flere konstruktører

En konstruktør behøver ikke at blive kommenteret, så længe der kun er en i en komponent, og Spring kan utvetydigt vælge den som den rigtige til at instantiere et nyt objekt. Når der er flere, skal du også kommentere den, der skal bruges af IoC-containeren.

Overvej Undskyld service eksempel:

@Component @RequiredArgsConstructor offentlig klasse ApologizeService {privat endelig Oversætter oversætter; privat endelig String besked; @Autowired public ApologizeService (Oversætteroversætter) {dette (oversætter, "undskyld"); } public String produce () {return translator.translate (meddelelse); }}

Ovenstående komponent kan valgfrit konfigureres med besked felt, som ikke kan ændres, efter at komponenten er oprettet (deraf manglen på et setter). Det krævede os således at give to konstruktører - en med fuld konfiguration og den anden med en implicit standardværdi af besked.

Medmindre en af konstruktørerne er kommenteret med en af dem @Autowired, @Indsprøjte eller @Ressource, Spring vil kaste en fejl:

Kunne ikke instantiere [...]: Ingen standardkonstruktører fundet;

Hvis vi ville kommentere Lombok-genereret konstruktør, skulle vi videregive kommentaren med en onConstructor parameter for @AllArgsConstructor:

@Component @RequiredArgsConstructor (onConstructor = @__ (@ Autowired)) offentlig klasse ApologizeService {// ...}

Det onConstructor parameter accepterer en række annoteringer (eller en enkelt kommentar som i dette specifikke eksempel), der skal placeres på en genereret konstruktør. Det dobbelte understregningsform er introduceret på grund af bagudkompatibilitetsproblemer. Ifølge dokumentationen:

Årsagen til den underlige syntaks er at få denne funktion til at fungere i javac 7-kompilatorer; det @__ type er en annotationsreference til annotationstypen __ (dobbelt understregning), som faktisk ikke findes; dette gør javac 7 forsinket med at afbryde kompileringsprocessen på grund af en fejl, fordi det er muligt, at en annoteringsprocessor senere opretter __ type.

5. Resume

I denne vejledning viste vi, at der ikke er behov for at foretrække feltbaseret DI frem for konstruktørbaseret DI med hensyn til øget kedelpladekode.

Takket være Lombok er det muligt at automatisere almindelig kodegenerering uden en præstationspåvirkning på runtime, forkortet lang, tilslørende kode til brugen af en enkeltlinjeannotation.

Koden, der blev brugt under vejledningen, er tilgængelig på GitHub.

streamalism.org