Waarom wordt er zoveel ingezet op DRY, SOLID en KISS?

Goede software is eenvoudig aan te passen, uit te breiden en te begrijpen. Ontwikkelprincipes zoals SOLID, DRY en KISS helpen daarbij, zeker bij grotere of langdurige projecten.

Oorsprong

Deze principes ontstonden uit de noodzaak om grote systemen beheersbaar te houden.

• SOLID – Robert C. Martin
• DRY – Andy Hunt & Dave Thomas
• KISS – sinds de jaren 60 gangbaar

Ze worden inmiddels breed toegepast binnen de industrie en aangeleerd op opleidingen.

SOLID

1. Single Responsibility Principle (SRP)

Een klasse mag maar één verantwoordelijkheid hebben.

Voorbeeld: Een User-klasse die ook e-mails verstuurt, is verantwoordelijk voor twee dingen. Verdeel dit over aparte klassen: UserManager en EmailService.

2. Open/Closed Principle (OCP)

Code moet uitbreidbaar zijn zonder bestaande code te wijzigen.

Voorbeeld:

interface Shape {
    public function area();
}
class Circle implements Shape {
public function area() {
return pi() * $this->radius ** 2;
}
}

Nieuwe vormen kunnen worden toegevoegd door het Shape-interface te implementeren, zonder bestaande klassen aan te passen.

3. Liskov Substitution Principle (LSP)

Subklassen moeten zich gedragen als vervanging voor hun superklasse.

Voorbeeld: Een Bird-klasse met een fly()-methode mag geen subklasse Penguin hebben die een fout gooit bij fly(). De subklasse mag het verwachte gedrag niet breken.

4. Interface Segregation Principle (ISP)

Voorkom dat klassen methoden moeten implementeren die ze niet nodig hebben.

Voorbeeld:

interface OnlinePayment {
    public function payOnline($amount);
}
interface OfflinePayment {
public function payOffline($amount);
}

Een klasse die alleen offline betalingen verwerkt, hoeft niets te weten van online logica.

5. Dependency Inversion Principle (DIP)

Afhankelijkheden moeten gebaseerd zijn op abstracties, niet op concrete implementaties.

Voorbeeld:

class PaymentService {
    public function __construct(PaymentProcessor $processor) { ... }
}

Door gebruik van een interface PaymentProcessor kun je eenvoudig wisselen tussen bijvoorbeeld PayPalProcessor of StripeProcessor, zonder PaymentService aan te passen.

DRY – Don’t Repeat Yourself

Herhaal geen logica. Dubbele code leidt tot fouten en lastig onderhoud.

Voorbeeld: Als je validatie voor een e-mailadres op meerdere plekken in je app gebruikt, stop deze dan in één herbruikbare functie.

KISS – Keep It Simple, Stupid

Houd oplossingen eenvoudig en direct. Vermijd over-engineering.

Voorbeeld: Gebruik geen ingewikkeld patroon als een eenvoudige if volstaat. Begrijpelijkheid gaat voor complexiteit.

Conclusie

Deze principes zorgen voor schonere, beter testbare en onderhoudbare code. Ze zijn geen regels die je altijd moet volgen, maar richtlijnen die helpen om bewuster te ontwikkelen.