Hoe begrijp je de SOLID-principes op basis van je…

SOLID — een verzameling van vijf principes voor objectgeoriënteerd ontwerp (ООД), die helpen bij het creëren van flexibele, uitbreidbare en gemakkelijk te onderhouden systemen. Gebaseerd op mijn ervaring, begrijp ik elk principe als:

S - Single Responsibility Principle (Principe van enkele verantwoordelijkheid): Elke klasse moet slechts één reden hebben om te veranderen. Dit betekent dat de klasse slechts verantwoordelijk moet zijn voor één specifieke functie of onderdeel van het systeem. Dit vergemakkelijkt het begrijpen, testen en aanpassen van de klasse, en minimaliseert bij wijzigingen de bijwerkingen.
```
class ReportGenerator {
    // Hoofdl responsibility: rapport genereren
    public void generateReport(Data data) {
        // Logica voor rapportgeneratie
    }

    // Schending van SRP: als deze klasse ook verantwoordelijk is voor het opslaan van het rapport
    // public void saveReport(Report report) { /* ... */ }
}
```

O - Open/Closed Principle (Open/gesloten principe): Software-entiteiten (klassen, modules, functies, etc.) moeten open zijn voor uitbreiding, maar gesloten voor modificatie. Dit wordt bereikt door gebruik te maken van abstracties (interfaces, abstracte klassen) en polymorfisme. Nieuwe functionaliteit wordt toegevoegd door nieuwe implementaties van bestaande abstracties te maken, zonder de bestaande code te wijzigen.

interface Shape {
    double calculateArea();
}

class Circle implements Shape {
    private double radius;
    public Circle(double radius) { this.radius = radius; }
    @Override
    public double calculateArea() { return Math.PI * radius * radius; }
}

class Square implements Shape {
    private double side;
    public Square(double side) { this.side = side; }
    @Override
    public double calculateArea() { return side * side; }
}

class AreaCalculator {
    // Open voor uitbreiding: nieuwe vormen kunnen worden toegevoegd zonder deze methode te wijzigen
    public double calculateTotalArea(Shape[] shapes) {
        double totalArea = 0;
        for (Shape shape : shapes) {
            totalArea += shape.calculateArea();
        }
        return totalArea;
    }
}

L - Liskov Substitution Principle (Liskov substitutieprincipe): Subtypen moeten volledig vervangbaar zijn door hun basistypen. Dit betekent dat clientcode die met het basistype werkt, correct moet werken met elk subtype zonder dat kennis van de specifieke implementatie nodig is. In de praktijk komt dit erop neer dat afgeleide klassen de contracten van de basisklasse of interface niet mogen schenden.

class Rectangle {
    protected int width;
    protected int height;

    public void setWidth(int width) { this.width = width; }
    public void setHeight(int height) { this.height = height; }

    public int getArea() { return width * height; }
}

class SquareLSP extends Rectangle {
    @Override
    public void setWidth(int width) {
        this.width = width;
        this.height = width; // Schending van LSP als client onafhankelijkheid verwacht
    }

    @Override
    public void setHeight(int height) {
        this.width = height;
        this.height = height; // Schending van LSP
    }
}

I - Interface Segregation Principle (Interfessche segregatie): Klanten moeten niet afhankelijk zijn van interfaces die ze niet gebruiken. Het is beter om veel kleine, specifieke interfaces te hebben dan één grote, "vette" interface. Dit vermindert de koppeling en stelt klassen in staat alleen die functies te implementeren die ze echt nodig hebben.

interface Worker { // "Vette" interface
    void work();
    void eat();
    void sleep();
}

interface Workable { // Gesegregeerde interfaces
    void work();
}

interface Feedable {
    void eat();
}

interface Sleepable {
    void sleep();
}

class HumanWorker implements Workable, Feedable, Sleepable {
    // Implementeert alle benodigde interfaces
    // ...
}

class RobotWorker implements Workable {
    // Implementeert alleen Workable, afhankelijk niet van Feedable en Sleepable
    // ...
}

D - Dependency Inversion Principle (Afhankelijkheidsomkering):

Modules van hogere niveau mogen niet afhankelijk zijn van modules van lagere niveau. Beiden moeten afhankelijk zijn van abstracties.
Abstracties mogen niet afhankelijk zijn van details. Details moeten afhankelijk zijn van abstracties. Dit principe wordt vaak geïmplementeerd via dependency injection, waarbij de afhankelijkheden van een klasse van buiten worden geleverd in plaats van door de klasse zelf te worden gemaakt. Dit vermindert de koppeling en vergemakkelijkt testen.

// Schending van DIP: HighLevelModule hangt rechtstreeks af van LowLevelModule
class LowLevelModule {
    public void doLowLevelStuff() { /* ... */ }
}

class HighLevelModule {
    private LowLevelModule lowLevel = new LowLevelModule(); // Directe afhankelijkheid

    public void doHighLevelStuff() {
        lowLevel.doLowLevelStuff();
    }
}

// Toepassing van DIP: beiden hangen af van abstractie
interface Service {
    void execute();
}

class ConcreteService implements Service {
    @Override
    public void execute() { /* Implementatiedetails */ }
}

class ClientModule {
    private final Service service; // Afhankelijkheid van abstractie

    // Afhankelijkheid wordt geïnjecteerd (bijvoorbeeld via constructor)
    public ClientModule(Service service) {
        this.service = service;
    }

    public void doSomething() {
        service.execute(); // Werkt met abstractie
    }
}

Het naleven van SOLID-principes heeft volgens mijn ervaring geleid tot het creëren van schonere, beter uitbreidbare en onderhoudbare code, wat cruciaal is voor de lange termijn ontwikkeling van softwareproducten.

Hoe begrijp je de SOLID-principes op basis van je ervaring?