S.O.L.I.D: de eerste vijf principes van Object Oriented Design (OOD)

Geschreven door: op maandag 23 maart 2015

Leestijd:

S.O.L.I.D is een acroniem voor de eerste vijf object-oriented design (OOD) principes van Robert C. Martin, of Uncle Bob

S.O.L.I.D. staat voor:

  • Single responsibility principle
  • Open closed principle
  • Liskov substitution principle
  • Interface segregation principle
  • Dependency inversion principle

Om dit artikel niet te lang te en te ingewikkeld te maken gaan we alleen in op de volgende onderwerpen:

  • Single responsibility principle
  • Open closed principle
  • Dependency inversion principle

Single responsibility principle

Single responsibility principle

S.R.P. in het kort. Dit principe vertelt ons:

“A class should have one and only one reason to change, meaning that a class should have only one job.”

Oftewel, een class moet maar één doel hebben en daarmee dus maar ook één reden hebben om te worden aangepast.

Single responsibility principle code

Bovenstaande code bevat twee classes die allebei één doel hebben. Veel ontwikkelaars zullen de neiging hebben om deze code in dezelfde classe te plaatsen, maar dat is volgens het S.R.P. principe dus niet juist.

Open-Closed Principle

Open-Closed Principle

Dit principe staat voor:

“Objects or entities should be open for extension, but closed for modification.”

Simpel gezegd: een class moet makkelijk uit te breiden zijn, zonder de gehele classe aan te passen.

Voorbeeld

Voor dit voorbeeld maken we gebruik van een rectangle class. Logischerwijs heeft een rectangle een hoogte en een breedte:

Open-Closed Principle code

Stel je voor dat je een collectie van rechthoeken hebt waarvan je de oppervlakte van wilt weten. Geen probleem dat kan met de volgende class:

Open-Closed Principle code 2

Maar als je nu ook de oppervlakte wilt berekenen van een cirkel, met dezelfde AreaCalculator heb je een probleem, wat je als volgt op zou kunnen lossen:

Open-Closed Principle code 3

Deze oplossing zal uiteraard gewoon werken, alleen als je van nog meer vormen zoals een driehoek wilt toevoegen moet je er weer een extra conditie worden toegevoegd. De class moet dus elke keer worden aangepast als er iets extra’s bijkomt. Nu is het in dit simpele voorbeeld geen probleem, maar in de echte wereld waar de code complex is, is dit wel een probleem.

De oplossing:

De oplossing is om een abstracte basis class te maken voor alle vormen met daarin een methode voor het berekenen van de oppervlakte.

Open-Closed Principle code 4

De Rectangle en de Circle classes komen er dan als volgt uit te zien:

Open-Closed Principle code 5

De areaCalculator ziet er dan als volgt uit:

Open-Closed Principle code 6

In andere woorden: het is nu gesloten voor veranderingen door het te openen voor uitbreidingen.

Dependency Inversion principle

Dependency Inversion principle

Dit principe vertelt ons:

“Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.”.

Dit klinkt misschien gek, maar is eenvoudig te begrijpen. Dit is het makkelijkste met een voorbeeld.

Voorbeeld

Je hebt misschien een bepaalde class die een wachtwoord reminder moet sturen. Hiervoor is een verbinding met de database nodig. Dit zou je op deze manier op kunnen lossen:

Dependency Inversion principle code 1

De DbConnection is een low level module en de PasswordReminder is een high level module. Volgens bovenstaande intentie van het principe klopt onze code dus niet.

Als je namelijk een wijziging wilt maken in de database verbinding moet dit overal worden aangepast. Daarnaast wordt ook het Open-Closed principe hiermee geschonden.

Oplossing

In bovestaande voorbeeld is moet het niet uit maken voor de PasswordReminder class welke database verbinding er wordt gebruikt.

Daarom plaatsen we de DbConnection in een interface.

Dependency Inversion principle code 2

De volledige implementatie ziet er dan als volgt uit:

Dependency Inversion principle code 3

Zoals je kunt zien in bovenstaande code zie je dat de high level en de low level module beide leunen op een abstractie.

Conclusie

Op het eerste oog lijken bovenstaande principes veel werk om te implementeren, maar op het lange termijn is je code eenvoudiger aan te passen, uit te breiden, testen en refactoren zonder problemen. 


Op De Hoogte Blijven?

Online Succes realiseren is een vak, een vak wat wij verstaan en waarover we je graag vertellen. Schrijf je in voor onze maandelijkse nieuwsbrief en blijf op de hoogte van trends, thema’s en succesverhalen.

Aanhef

Andere blogartikelen

Bel 072 5345 888
Meer dan 40 bedrijven vertrouwen op ons
Allrig is de alles in een leverancier binnen de energie-industrie
Aliancys is een toonaangevend wereldwijd bedrijf actief in de verkoop van kwaliteitsharsen
ERIKS is een toonaangevende en innovatieve leverancier aan de procesindustrie en aan machinebouwers, die zowel de rol van specialist als die van brede MRO-leverancier vervult
Industrieel dienstverlener Heinen & Hopman Engineering uit Bunschoten is dé wereldwijde specialist op het gebied van klimaatbeheersing
Handicare is een internationale organisatie die ouderen helpt om hun dagelijks leven gemakkelijker te maken door het produceren van hoogwaardige trapliften
Onze Middelen en Technologieën
Microsoft partner
Adobe partner
Asp dotnet
Google analytics
Google adwords
TelefoonE-mail