De vraag die steeds terugkomt
Principes als SOLID gelden al lang als de gouden standaard voor objectgeoriënteerd programmeren. Ze helpen developers code te schrijven die onderhoudbaar, schaalbaar en robuust is. Maar softwarearchitecturen veranderen — zeker nu we van monolithische naar gedistribueerde systemen gaan. Dus duikt steeds dezelfde vraag op: zijn deze principes nog relevant, of zijn het overblijfselen uit een vervlogen tijd?
Een mentor stelde me die vraag een aantal jaar geleden voor het eerst. Sindsdien heb ik er tientallen gesprekken over gevoerd met collega's, vakgenoten en klanten. Onlangs opperde een collega tijdens een technische review dat de SOLID-principes vooral passen bij monolithische architecturen en minder relevant zijn in gedistribueerde systemen.
Een redelijke hypothese. Maar hij klopt niet — al is de reden interessant.
SOLID in gedistribueerde systemen
De SOLID-principes — single responsibility, open-closed, Liskov substitution, interface segregation en dependency inversion — zijn bedacht om code modulairder en beter beheersbaar te maken. In traditionele monolithische architecturen helpen ze de complexiteit te beperken die ontstaat als applicaties groeien.
In gedistribueerde systemen zijn services van elkaar geïsoleerd en communiceren ze via een netwerk. Daar kan strikt vasthouden aan SOLID soms overdreven lijken. Elke microservice heeft al één verantwoordelijkheid. Interface segregation regel je op de API-grens. Het architectuurpatroon dwingt zelf al een deel af van wat SOLID moest bereiken.
Maar daar zit de valkuil: veel services die bedoeld waren als “microservice”, worden te groot en te complex. Ze lijken dan meer op een traditionele monoliet dan op de lichte, onafhankelijke services die ze hadden moeten zijn. In die gevallen zijn de SOLID-principes net zo onmisbaar als altijd om het systeem beheersbaar en schaalbaar te houden.
De architectuur maakt principes niet overbodig. Ze verandert waar je ze toepast.
Python en pragmatisme
Neem Python: een taal die OOP volledig ondersteunt, maar waarin projecten zich vaak niet strikt aan SOLID houden. Dat ligt niet aan Python. Het zit in hoe de taal in de praktijk wordt gebruikt.
De ontwerpfilosofie van Python, vastgelegd in The Zen of Python, legt de nadruk op eenvoud en leesbaarheid. Dat leidt soms tot een pragmatische kijk op softwareontwerp, waarin “het werkt nu” voorgaat op structurele discipline.
Kijk naar FastAPI, een populair webframework voor het bouwen van API's. FastAPI laat goed zien hoe je clean code en de SOLID-principes effectief toepast in het Python-ecosysteem. Het project is zorgvuldig opgezet, met een duidelijke scheiding van verantwoordelijkheden en een doordacht objectgeoriënteerd ontwerp. Dat succes is geen toeval: die architectuurdiscipline heeft direct bijgedragen aan de adoptie en de onderhoudbaarheid.
In sommige landen, zoals Nederland, telt de groep Python-developers relatief weinig senioren vergeleken met talen als Java of C#. Dat komt doordat Python pas recent zo populair is geworden, doordat universiteiten het veel gebruiken en doordat veel developers instromen zonder klassieke achtergrond in software engineering. Veel starters op de arbeidsmarkt leerden Python als eerste taal, vaak zonder echt kennis te maken met de klassieke principes van software engineering.
Daar ligt een kans. Ervaren developers die thuis zijn in andere OOP-talen, kunnen hun kennis van SOLID en clean architecture meenemen naar het Python-ecosysteem. Zo begeleiden ze minder ervaren developers en tillen ze de kwaliteit van Python-projecten naar een hoger niveau. De principes zijn taalonafhankelijk. De ervaring is overdraagbaar.
De snelheidsval
Nieuwe ontwikkeltools maken het makkelijker dan ooit om snel code te schrijven. Maar snelheid en kwaliteit staan op gespannen voet.
Staat een team onder druk om snel te leveren, dan gaat snelheid vaak voor structuur. Zo leen je tijd van de toekomst. Technische schuld die zich opstapelt en die je niet beheert, levert grote problemen op voor wie de codebase erft — of dat nu hetzelfde team is of later iemand anders.
Goede werkwijzen opnieuw oppakken gaat niet over een puinhoop opruimen. Het gaat over een fundament bouwen dat toekomstige eisen aankan.
Deze principes later in het ontwikkelproces toepassen is veel duurder dan er vroeg mee beginnen. Zonder die vroege investering lopen de kosten voor teams steeds verder op: zodra de schuld onbeheersbaar wordt, moeten ze componenten — of complete applicaties — opnieuw bouwen.
Evolutie, geen uitsterven
Of werkwijzen in software relevant zijn, is geen zwart-witkwestie. Ze zijn niet levend of dood — ze ontwikkelen zich.
In de vroege fase van een project lijkt strikte naleving misschien niet nodig. Een prototype heeft geen dependency inversion nodig. Een MVP heeft geen interface segregation nodig. Maar naarmate een project volwassener wordt en groeit, worden deze werkwijzen onmisbaar om de code gezond te houden.
De uitdaging is om continu af te wegen: wanneer pas je discipline toe, wanneer stel je die uit, en wanneer is uitstellen duurder geworden dan invoeren? Dat oordeel — niet de principes zelf — onderscheidt ervaren engineers van engineers die hun vak nog aan het leren zijn.
Succes in softwareontwikkeling komt niet voort uit het blind volgen van gevestigde principes. Het komt voort uit het bewust en doordacht toepassen van goede werkwijzen — afgestemd op de context, de randvoorwaarden en de koers van het product op de lange termijn.
De beslissingen die je tijdens de ontwikkeling neemt, bepalen uiteindelijk of een product een blijvende aanwinst wordt of een last die je overdraagt aan iemand anders.