Spring Boot: koreanska utvecklares standard och inversion of control

Är Sydkorea en ”Spring-republik”?

Om du vill få jobb som backendutvecklare i Korea finns det en fråga du nästan inte kan undvika: ”Kan du Spring?”

Om man går in på jobbsajter ser man att nio av tio annonser uttryckligen skriver ”erfarenhet av Spring Boot” bland kraven. Det har till och med lett till uttrycket ”Spring-republik”. När jag gick på universitetet trodde jag att det bara handlade om en trend.

”Kan man inte bara skriva det i Java? Varför måste man använda det där tunga Spring?” ”Är inte Node.js eller Python (Django) enklare?”

Men när jag kom ut i arbetslivet och fick uppleva stora projekt på riktigt förstod jag varför. Spring var inte någon tillfällig modefluga, utan en standardiserad arbetsbänk som förfinats av mängder av erfarna utvecklare för att stora och komplexa enterprise-system skulle kunna byggas säkert och snabbt.

Den här serien handlar just om hur man bygger ett slott som inte rasar, en Monolith, ovanpå den där standardiserade arbetsbänken.

Ramverk: varför man inte kan göra allt på sitt eget sätt

Innan vi går in i det tekniska på allvar finns det en sak som måste redas ut. Vad är egentligen ett ramverk? Och hur skiljer det sig från ett bibliotek?

Jag nämnde det kort i den förra Re: Booting-serien, men den avgörande skillnaden handlar i slutänden om en enda fråga: vem håller i kontrollen?

Spring är ett ramverk. Att använda Spring är därför nästan som att skriva under ett löfte: ”jag lägger min egen stil lite åt sidan och arbetar på det sätt som Spring kräver.” Kärnan i det där ”på det sätt som Spring kräver” är precis dagens ämne: Inversion of Control (IoC).

”Snälla, sluta använda new överallt”

Den första regeln i det där löftet var ganska chockerande. I princip sa den: sluta använda new, trots att det är en av Javas mest grundläggande byggstenar.

På universitetet var det självklart: om jag behövde ett objekt skrev jag MemberService service = new MemberService();. Om jag behöver något, skapar jag det själv och använder det. Vad skulle vara konstigt med det?

Men när jag efter att ha börjat arbeta öppnade ett Spring Boot-projekt kunde jag inte hitta nyckelordet new någonstans i koden. I stället var den full av märkliga annoteringar som @Autowired och @RequiredArgsConstructor.

”Vänta nu, om ingen skapar objektet, hur anropas då metoden? Fungerar det här verkligen?”

När jag frågade en senior utvecklare fick jag ett svar som lät frustrerande svävande: ”Spring Container injicerar det åt oss, så vi behöver inte skapa det själva. Tvärtom blir koden mycket svårare att underhålla senare om du använder new direkt.”

Jag kunde inte acceptera det. Jag var ju ägaren till koden jag skrev, så varför fick jag inte ens skapa ett objekt fritt? Det kändes nästan som en Spring-diktatur.

Kocken och ingrediensansvarig (IoC & DI)

För att förstå varför den här regeln, som kan verka auktoritär, faktiskt behövs, byter vi metafor och går in i ett restaurangkök.

1. Det traditionella sättet (jag bestämmer)

Jag är en kock, alltså en Class. För att laga mat behöver jag en kniv, alltså en Dependency.

2. Springs sätt (Spring bestämmer)

Jag är fortfarande kocken. Men den här gången finns det också en ansvarig för ingredienser och verktyg: Spring Container.

Med andra ord: i stället för att jag själv hanterar resurserna jag behöver, sköts de utifrån och levereras till mig. Det är just det som är Inversion of Control (IoC: Inversion of Control), och den konkreta tekniken för att göra det heter Dependency Injection (DI).

[Code Verification] Varför är new farligt?

Det räcker inte att bara prata om det. Vi måste jämföra det direkt i kod. Föreställ dig att vi bygger ett kortbetalningssystem.

1. Dåligt exempel: direkt instansiering (hård koppling)

public class PaymentService {
    // Jag valde och skapade sjalv ett Samsung Card (med new)
    private final SamsungCard card = new SamsungCard();

    public void pay() {
        card.payment(); // Bara betalning med Samsung Card
    }
}

Problemet: en dag säger chefen: ”Vi byter till Hyundai Card, avgifterna är lägre!” Då måste jag öppna koden i PaymentService och byta ut varje SamsungCard mot HyundaiCard. Och om den koden finns på hundra ställen? Då är övertiden given.

2. Bra exempel: dependency injection (lös koppling)

public class PaymentService {
    private final Card card; // Specificera inte en konkret kortutgivare (anvand granssnittet)

    // Konstruktorinjektion: lita pa att nagon utifran raker over kortet
    public PaymentService(Card card) {
        this.card = card;
    }

    public void pay() {
        card.payment();
    }
}

Nu bryr sig inte PaymentService längre om vilken konkret kortimplementation som skickas in.

Det här är kärnan i det som man i praktiken menar med ”kod som är lätt att underhålla”, eller OCP-principen. Och det är just den flexibiliteten som gör att så många använder Spring Boot.

Spring Container: ett hotell för objekt

Vem är då den här ”ansvariga” som skapar objekt och delar ut dem? Det är precis det som Spring Container är.

I samma ögonblick som vi startar en Spring Boot-server med run händer det väldigt mycket under ytan.

Det enda vi egentligen behöver göra är att sätta en lapp på klassen som säger ”hantera det här”, till exempel med @Service. Resten sköter Spring, ungefär som en enorm hotellchef som håller ordning på alla gäster.

Praktiskt råd: använd konstruktionsinjektion

Spring erbjuder flera sätt att injicera beroenden: fältinjektion med @Autowired, setter-injektion och konstruktionsinjektion. Men i riktiga projekt rekommenderas nästan alltid konstruktionsinjektion. Det är också mönstret som ofta används tillsammans med Lomboks @RequiredArgsConstructor.

@Service
@RequiredArgsConstructor // Detta skapar konstruktorinjektionen automatiskt.
public class OrderService {
    // final kan anvandas, sa det ar sakert
    private final PaymentService paymentService;
}

Varför?

Avslutning: inte en trollkarl, utan en dirigent

I början kände jag motstånd mot Spring, eftersom det verkade som om det bara svingade runt med min kod hur det ville. Nu ser jag det annorlunda. Spring är inte en diktator som gör livet surt för mig, utan en kompetent dirigent som organiserar komplexa relationer mellan objekt.

Tack vare det lägger jag mindre tid på att fundera över ”vilket objekt ska jag skapa?” och mer tid på ”hur bygger jag affärslogiken med det här objektet?”. Det är förmodligen därför så många utvecklare i Korea fortfarande håller så hårt fast vid Spring.

Nu har vi lämnat över objekthanteringen till Spring. Servern är redo att startas. Men en webbapplikation kör inte ensam: den måste prata med frontend. På PHP-tiden var det bekvämt eftersom HTML och kod låg i samma fil. Varför separerar man då idag frontend, med Vue eller React, från backend? Och varför får man ett rött CORS-fel så fort man försöker koppla ihop de två?

Nästa gång ska vi titta på förändringen i webbarkitektur, SSR vs CSR, och den verkliga identiteten bakom CORS, väggen som står mellan dem.