Polymorfisme in de praktijk
Beeld je in dat je een klasse EersteMinister
hebt met een methode Regeer
en je wilt een eenvoudig land simuleren.
De EersteMinister
heeft toegang tot tal van ministers die hem kunnen helpen (inzake milieu, binnenlandse zaken (BZ) en economie). Zonder de voordelen van polymorfisme zou de klasse EersteMinister
er zo kunnen uitzien (slechte manier!):
Dit voorbeeld is gebaseerd op een briljante StackOverflow post waarin de vraag "What is polymorphism, what is it for, and how is it used?" wordt behandeld (https://stackoverflow.com/questions/1031273/what-is-polymorphism-what-is-it-for-and-how-is-it-used).
De MinisterVanMilieu
zou er zo kunnen uitzien (de methodenimplementatie mag je zelf verzinnen):
De MinisterVanEconomie
-klasse heeft dan weer heel andere publieke methoden. En de MinisterBZ
ook weer totaal andere.
Je merkt dat de EersteMinister
(of de programmeur van deze klasse) aardig wat specifieke kennis moet hebben van de vele verschillende departementen van het land. Bovenstaande code is dus zeer slecht en vloekt tegen het abstractie-principe van OOP: onze klasse moeten veel te veel weten van andere klassen, wat vermeden moet worden. Telkens er zaken binnen een specifieke ministerklasse wijzigen moet dit ook in de EersteMinister
aangepast worden. Dankzij polymorfisme en overerving kunnen we dit alles veel mooier oplossen!
Ten eerste: We verplichten alle ministers dat ze overerven van de abstracte klasse Minister
die maar 1 abstracte methode heeft Adviseer
:
Ten tweede: Het leven van de EersteMinister wordt plots véél makkelijker. Hij kan gewoon de Adviseer
methode aanroepen van iedere minister:
En ten derde: En we kunnen hem nog helpen door met een array of List<Minister>
te werken zodat hij ook niet steeds de "namen" van z'n ministers moet kennen. Dankzij polymorfisme mag dit:
En wie zei dat het regeren moeilijk was?!
Merk op dat dit voorbeeld ook goed gebruik maakt van compositie.
Last updated