SOLID zijn vijf ontwerpprincipes voor het bouwen van onderhoudbare, flexibele OOP-systemen. Elk richt zich op een veel voorkomende oorzaak van stijf, fragiel code.
SOLID zijn vijf ontwerpprincipes voor het bouwen van onderhoudbare, flexibele OOP-systemen. Elk richt zich op een veel voorkomende oorzaak van stijf, fragiel code.
| Letter | Principe | Betekenis in één zin |
|---|
| S | Single Responsibility | Een klasse mag maar één reden hebben om te veranderen |
| O | Open/Closed | Open voor uitbreiding, gesloten voor wijziging |
| L | Liskov Substitution | Subtypes moeten bruikbaar zijn waar het basistype gebruikt wordt |
| I | Interface Segregation | Veel kleine interfaces zijn beter dan één grote |
| D | Dependency Inversion | Afhankelijk van abstracties, niet van concrete klassen |
# Dependency Inversion: high-level code depends on an abstraction
class Notifier: # abstraction
def send(self, msg): ...
class EmailNotifier(Notifier):
def send(self, msg): print("email:", msg)
class OrderService:
def __init__(self, notifier: Notifier): # injected abstraction
self.notifier = notifier # not "new EmailNotifier()"
def place(self):
self.notifier.send("order placed") # works with ANY Notifier
OrderService is niet specifiek afhankelijk van email — vervang het door SMS of een test-double zonder het aan te raken (D). Het toevoegen van een nieuw notifier-type vereist geen wijziging van OrderService (O).
SOLID is richtlijn, geen wet. Te veel toepassing ervan — een interface per klasse, indirectheid overal — leidt tot "abstraction soup" die moeilijker te volgen is dan het probleem dat het zou moeten oplossen.
SOLID biedt een gedeelde diagnostische taal: reviewers kunnen benoemen waarom een klasse moeilijk te wijzigen is ("dit schendt SRP") in plaats van op smaak te discussiëren.
Toepasselijk toegepast, reduceren de principes ketingreacties — wijzigingen blijven lokaal, nieuwe features breiden uit in plaats van herschrijven, en tests kunnen nep-afhankelijkheden voor echte vervangen.