Forklare centrale backend-designprincipper som Separation of Concerns samt SRP-, ISP- og DIP-principper.
Demonstrere hvordan principperne anvendes i praksis gennem refaktorering af en eksisterende klasse.

Dykke ned i teori bag principperne, se tilbage på tidligere læringsobjekter.
Derefter analyserede jeg en konkret klasse fra min microservice, som oprindeligt havde for mange ansvarsområder og derfor brød flere principper.
Klassen blev refaktoreret, og jeg dokumenterede ændringerne for at vise, hvordan principperne forbedrede både struktur, testbarhed og kobling.

Separation of Concerns (SoC) SoC handler om at opdele et system i veldefinerede dele, hvor hver del har sit eget afgrænsede ansvar.
Det gør koden lettere at forstå, vedligeholde og teste.

SRP – Single Responsibility Principle SRP siger, at en klasse kun bør have ét ansvar og kun én grund til at ændre sig.
Det reducerer kompleksitet og gør fejl mindre kritiske.

ISP – Interface Segregation Principle Dette princip handler om, at interfaces skal være små og fokuserede, så klasser kun afhænger af det, de faktisk bruger.
Det skaber løs kobling og fleksibilitet.

DIP – Dependency Inversion Principle DIP betyder, at høj-niveau logik skal afhænge af abstraktioner og ikke konkrete implementeringer.
Det gør systemet udskifteligt og mere modulært.

---

Færdighed: Anvendelse af principperne i praksis

I mit arbejde med refaktoreringen undersøgte jeg, hvordan principperne typisk anvendes i moderne backend-arkitektur.
I stedet for at bruge et stort interface eller komplekse klasser, fokuserede jeg på at opdele funktionalitet og flytte detaljer til mindre, dedikerede komponenter.

---

Kompetencer: Anvendelse i min egen applikation

Jeg arbejdede konkret med klassen GoogleResultShaper, som tidligere:

• håndterede parsing af Google Vision-data
• udtrak logoer, OCR, web entities og objekter
• beregnede scoringslogik
• afledte brand og maskintype
• byggede hele resultatet (summary + evidence)

Klassen havde for mange ansvarsområder og brød både Separation of Concerns, SRP og DIP. Efter refaktorering, udgående afhængigheder bliver injiceret og abstraheret (DIP):

Ansvaret blev desuden opdelt:

• Parseren håndterer al udtrækning af værdier
• BrandResolver håndterer logik omkring brands
• TypeResolver håndterer maskintype-logik
• GoogleResultShaper koordinerer kun processen, men gør ikke det tunge arbejde selv
• IResultShaper er lille og fokuseret (ISP) med èn metode, Shape

Mine ændringer har medført:

• lavere kobling mellem komponenter
• markant forbedret testbarhed
• bedre fleksibilitet for fremtidige udvidelser
• tydeligere opdeling
• en mere robust og vedligeholdelsesvenlig microservice

Gennem denne refaktorering har jeg fået en dybere forståelse for, hvordan Separation of Concerns og SRP-, ISP- og DIP-principperne hænger sammen i praksis.
Jeg har især fået øjnene op for, hvor hurtigt en klasse kan få for mange ansvarsområder, og hvor meget det hjælper at bryde logik ud i mindre komponenter.
Desuden har arbejdet med Dependency Injection og abstraherede interfaces givet mig en bedre forståelse for Dependency Inversion Principle og værdien af løs kobling.
Det har også gjort det tydeligt, hvor meget mere testbar, fleksibel og vedligeholdelsesvenlig min kode bliver, når hver komponent har et klart defineret ansvar.

---