Java: Systemtenkningen jeg tok med meg videre

Java er ikke et språk jeg bruker daglig lenger. Men det er språket som lærte meg å tenke i systemer — og den tenkningen bruker jeg hver eneste dag, bare i andre språk.

Da jeg jobbet med Java i en enterprise-kontekst, ble jeg tvunget til å tenke annerledes enn når du skriver en rask prototype. Store systemer med mange utviklere, lange livssykluser og strenge krav til vedlikeholdbarhet. Det er en verden der ad hoc-løsninger ikke overlever, og der strukturen i koden betyr like mye som funksjonaliteten.

Hva Java-verdenen lærte meg

Interfaces som kontrakter. Java lærte meg å designe API-er før implementasjon. Du definerer et interface, avtaler kontrakten, og implementasjonen kan byttes ut uten at resten av systemet vet det. Det virker kanskje overdrevet for små prosjekter, men for et system som vokser er det uvurderlig.

Det samme prinsippet bruker jeg nå overalt. I Go med implicit interface satisfaction — der du ikke engang trenger å deklarere at en type implementerer et interface. I TypeScript med abstrakte typer og dependency injection. Grunnideen er den samme: skill mellom hva noe gjør og hvordan det gjør det.

Dependency injection. Spring Framework sin DI-container var min introduksjon til løs kobling. Konseptet er enkelt: en komponent oppretter ikke sine egne avhengigheter, men mottar dem utenfra. Det gjør kode testbar, modulær og enklere å endre.

Nå bruker jeg det i Go med constructor injection, i FastAPI med Depends(), og i React med context providers. Verktøyene er forskjellige, men tankegodset er identisk.

Lagdelt arkitektur. Java-prosjekter har typisk klare lag: presentasjon, forretningslogikk, dataaksess. Det kan føles tungt for en liten app, men for større systemer gir det deg muligheten til å endre ett lag uten å berøre resten. Når jeg designer et system nå — selv et lite et — tenker jeg automatisk i lag: hva er UI, hva er logikk, hva er data?

Mønsteret som oversetter til alt

Service-mønsteret fra Java oversetter direkte til andre språk:

public interface CourseService {
    List<Course> findAll();
    Optional<Course> findById(String id);
    Course create(CreateCourseRequest request);
}

public class CourseServiceImpl implements CourseService {
    private final CourseRepository repository;
    private final EventPublisher events;

    public CourseServiceImpl(CourseRepository repository, EventPublisher events) {
        this.repository = repository;
        this.events = events;
    }

    @Override
    public Course create(CreateCourseRequest request) {
        Course course = Course.from(request);
        repository.save(course);
        events.publish(new CourseCreatedEvent(course.getId()));
        return course;
    }
}

Interface foran implementasjon. Avhengigheter injisert via konstruktøren. Forretningslogikk separert fra infrastruktur. Når jeg ser Go-koden for Tuli sin backend, gjenkjenner jeg det samme mønsteret — bare uttrykt med Go sin enklere syntaks. Når jeg skriver TypeScript-tjenester i Next.js, er strukturen den samme.

Det er kanskje det viktigste jeg tok med meg: gode arkitekturprinsipper er ikke språkspesifikke. De er universelle.

Typesikkerhet som tenkemåte

Java sitt strenge typesystem føltes rigid da jeg lærte det. Hvorfor må jeg deklarere typen på alt? Hvorfor kan jeg ikke bare sende inn det som fungerer?

Nå forstår jeg verdien. TypeScript sitt typesystem er inspirert av mange av de samme ideene — og Go sin kompilator fanger feil som dynamiske språk lar gli gjennom. Erfaringen med Java ga meg en dyp verdsetting av typesikkerhet som et verktøy for å tenke klarere om kode, ikke bare som en begrensning.

Hvorfor dette er relevant

Jeg nevner Java ikke fordi det er et språk jeg bruker, men fordi det formet måten jeg tenker. Interfaces, DI, lagdelt arkitektur, typesikkerhet — dette er prinsipper som fungerer uavhengig av om du skriver Go, TypeScript eller Python.

Hvis du bare har jobbet med dynamiske språk, er det verdt å forstå hva enterprise-verdenen bringer til bordet. Ikke nødvendigvis koden — men tenkemåten.