streamalism.org

1. Introduksjon

Lombok er et ekstremt nyttig bibliotek som overvinner kokerplatekoden. Hvis du ikke er kjent med det ennå, anbefaler jeg på det sterkeste å ta en titt på forrige opplæring - Introduksjon til Project Lombok.

I denne artikkelen vil vi demonstrere brukervennligheten når den kombineres med vårens Konstruktørbasert avhengighetsinjeksjon.

2. Konstruktørbasert avhengighetsinjeksjon

En god måte å koble avhengigheter om våren ved hjelp av cinstruktørbasert avhengighetsinjeksjon. Denne tilnærmingen tvinger oss til å eksplisitt overføre komponentens avhengighet til en konstruktør.

I motsetning til Feltbasert avhengighetsinjeksjon, det gir også en rekke fordeler:

• ikke behov for å lage en testspesifikk konfigurasjonskomponent - avhengigheter injiseres eksplisitt i en konstruktør
• konsekvent design - alle nødvendige avhengigheter blir vektlagt og ivaretatt av konstruktørens definisjon
• enkle enhetstester - reduserte Spring Framework's overhead
• gjenvunnet bruksfrihet endelig søkeord

På grunn av behovet for å skrive en konstruktør bruker det imidlertid å føre til en betydelig større kodebase. Tenk på de to eksemplene på HilsenService og FarvelService:

@Komponent offentlig klasse GreetingService {@Autowired privat oversetteroversetter; public String produce () {return translator.translate ("hei"); }}

@Komponent offentlig klasse FarewellService {privat slutt Oversetteroversetter; public FarewellService (Oversetteroversetter) {this.translator = oversetter; } public String produce () {return translator.translate ("bye"); }}

I utgangspunktet gjør begge komponentene det samme - de kaller en konfigurerbar Oversetter med et oppgavespesifikt ord.

Den andre variasjonen er imidlertid mye mer forvirret på grunn av konstruktørens kjeleplate som egentlig ikke gir noen verdi til koden.

I den nyeste vårutgivelsen trenger ikke konstruktøren å bli merket med @Autowired kommentar.

3. Konstruktørinjeksjon med Lombok

Med Lombok, er det mulig å generere en konstruktør for enten alle klassens felt (med @AllArgsConstructor) eller alle endelig klassens felt (med @RequiredArgsConstructor). Videre, hvis du fortsatt trenger en tom konstruktør, kan du legge til en ekstra @NoArgsConstructor kommentar.

La oss lage en tredje komponent, analog med de to foregående:

@Component @RequiredArgsConstructor offentlig klasse ThankingService {privat slutt Oversetter oversetter; public String produce () {return translator.translate ("takk"); }}

Ovennevnte kommentar vil forårsake Lombok å generere en konstruktør for oss:

@Komponent offentlig klasse ThankingService {privat slutt Oversetteroversetter; public String thank () {return translator.translate ("thank you"); } / * Generert av Lombok * / public ThankingService (oversetteroversetter) {this.translator = oversetter; }}

4. Flere konstruktører

En konstruktør trenger ikke å bli kommentert så lenge det bare er en i en komponent, og Spring kan utvetydig velge den som den rette for å sette i gang et nytt objekt. Når det er flere, må du også kommentere den som skal brukes av IoC-beholderen.

Vurder Beklager service eksempel:

@Component @RequiredArgsConstructor offentlig klasse ApologizeService {privat slutt Oversetter oversetter; privat slutt Stringmelding; @Autowired public ApologizeService (Oversetteroversetter) {dette (oversetter, "beklager"); } public String produce () {return translator.translate (melding); }}

Komponenten ovenfor er valgfritt konfigurerbar med beskjed felt som ikke kan endres etter at komponenten er opprettet (derav mangelen på et setter). Det krevde oss derfor å gi to konstruktører - en med full konfigurasjon og den andre med en implisitt, standardverdi for beskjed.

Med mindre en av konstruktørene er merket med noen av dem @Autowired, @Injiser eller @Ressurs, Våren vil kaste en feil:

Kunne ikke starte [...]: Fant ingen standardkonstruktører;

Hvis vi ønsket å kommentere Lombok-generert konstruktør, måtte vi passere kommentaren med en onConstructor parameteren til @AllArgsConstructor:

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

De onConstructor parameter aksepterer en rekke merknader (eller en enkelt merknad som i dette spesifikke eksemplet) som skal settes på en generert konstruktør. Det doble understrekingsidiomet er introdusert på grunn av problemer med bakoverkompatibilitet. I følge dokumentasjonen:

Årsaken til den rare syntaksen er å få denne funksjonen til å fungere i javac 7-kompilatorer; de @__ type er en merknadshenvisning til merketypen __ (dobbel understreking) som faktisk ikke eksisterer; Dette gjør at javac 7 forsinker å avbryte kompileringsprosessen på grunn av en feil fordi det er mulig at en merkeprosessor senere vil opprette __ type.

5. Sammendrag

I denne opplæringen viste vi at det ikke er behov for å favorisere feltbasert DI fremfor konstruktørbasert DI når det gjelder økt kjeleplatekode.

Takket være Lombok er det mulig å automatisere vanlig kodegenerering uten ytelsespåvirkning på kjøretid, forkortet lang, tilslørende kode til bruk av en enkeltlinjeanmerkning.

Koden som ble brukt under opplæringen, er tilgjengelig på GitHub.