SOLID software ontwikkeling

Jeroen 02 januari 2016
Door Jeroen

SOLID software ontwikkeling

Wanneer een ontwikkelteam in een Agile/Scrum omgeving gaat ontwikkelen, veranderd er misschien meer dan je zou denken.

Wanneer een ontwikkelteam in een Agile/Scrum omgeving gaat ontwikkelen veranderd er misschien meer dan je zou denken. Voorheen met het watervalmodel, voor het ontwikkelen begon, was in grote lijnen al duidelijk wat de uiteindelijke functies binnen de software zouden zijn. Het ontwikkelteam kiest een architectuur die aan deze functies voldoet en kan er van uitgaan dat deze architectuur zal voldoen voor de levensduur van de applicatie.

Wanneer voor een Agile omgeving gekozen wordt, zal van tevoren niet vast staan wat de functies binnen een applicatie uiteindelijk zullen zijn. Bij Agile wordt er rekening gehouden met veranderende wensen en is daar in vele malen flexibeler in dan het watervalmodel. Dit betekent niet alleen een verandering in methodiek, maar ook de ontwikkelde software moet flexibel genoeg zijn om deze veranderingen mogelijk te maken. Tegelijkertijd moet de software ook onderhoudbaar blijven.
Om dit mogelijk te maken zijn er een aantal best practices gebundeld tot de SOLID principes. Met de SOLID principes en de overige DataLeaf richtlijnen in het achterhoofd zal hierdoor een architectuur ontstaan welke modulair, veilig en goed gescheiden is.

SRP: Single Responsibility Principle

Iedere methode, klasse of variabele moet maar één functie uitoefenen en dus maar één verantwoordelijkheid hebben. Dit heeft als gevolg dat door het wijzigen van deze methode, klasse of variabele maar op één enkele functie geraakt wordt. Zo zou een methode voor het toevoegen van een record aan de database, niet ook moeten zorgen voor het loggen van fouten. Dit moet in een aparte klasse/methode gebeuren.

OCP: Open Closed Principle

Je klassen moeten open zijn voor uitbreiding van gedrag, maar gesloten voor het wijzigen van gedrag. Met dit principe in het achterhoofd kunnen je functies verrijkt worden, maar kan je er ook altijd vanuit gaan dat het basisgedrag functioneert zoals het bedoeld is. Overerving is de meest logische manier om dit toe te passen. Een voorbeeld hiervan is een interface Vorm welke de eigenschap ‘Oppervlakte’ definieert, verschillende vormen zullen deze interface implementeren en hun eigen berekening voor de oppervlakte implementeren zonder dat er iets veranderd aan de ‘Vorm’ interface.

LSP: Liskov Subsitution Principle

LSP zegt dat wanneer een klasse overerft van een andere klasse of een interface implementeert, je er vanuit moet kunnen gaan dat de klasse deze functies heeft. Het komt hier eigenlijk op neer: gebruik interfaces en zorg ervoor dat je ook naar de interfaces verwijst in plaats van naar de klassen. Een voorbeeld hiervan is het gebruik maken van een log interface, deze is dan altijd te vervangen door bijvoorbeeld een logger op de database of een logger naar tekstbestanden. Er hoeft dan niets veranderd te worden op de plaatsen waar de logger wordt aangesproken.

ISP: Interface Segregation Principle

ISP staat voor het scheiden van interfaces, zodat er nooit klassen zullen zijn die niet alle methoden binnen de interface implementeren. Maak bijvoorbeeld in plaats van een CRUD interface een aparte interface voor Create, Update en Delete. Hiermee voorkom je dat je methoden moet gaan implementeren welke je helemaal niet wil gebruiken. Bijvoorbeeld wanneer een entiteit niet verwijderd mag worden, deze zal dus niet de Delete methode uit de CRUD interface moeten implementeren.

DIP: Dependency Inversion Principle

DIP staat voor het scheiden van abstractie niveaus binnen de code. Zorg ervoor dat complexe logica niet in dezelfde klasse staat als low-level code. Bijvoorbeeld het aansturen van hardware of het schrijven naar een log binnen in een berekening moet voorkomen worden. De berekenings logica kan dan beter een instantie van een log-interface aanspreken, waardoor de low-level code makkelijk te vervangen is of verbeterd kan worden. Hierdoor blijft de berekening zeker hetzelfde wanneer er van logger veranderd wordt.

 

 



 

Schrijf je in voor onze nieuwsbrief

Schrijf je in en ontvang vier keer per jaar per email het laatste nieuws over software ontwikkeling en DataLeaf.

Ik zorg er voor dat uw bedrijfsproces inzichtelijk wordt!