Polymorfisme in de praktijk
Beeld je in dat je een klasse President
hebt met een methode RunTheCountry
(voorbeeld van StackOverflow ). De president heeft toegang tot tal van adviseurs die hem kunnen helpen (inzake miltair, binnenlands beleid, economie). Zonder de voordelen van polymorfisme zou de klasse President
er zo kunnen uitzien, slechte manier:
De MilitaryMinister
zou er zo kunnen uitzien:
De HealthOfficial
-klasse heeft dan weer heel andere publieke methoden. En die ForeignSecretary
ook weer totaal andere.
Je merkt dat de president (of de programmeur van deze klasse) aardig wat specifieke kennis moet hebben van de vele verschillende departementen van het land. De verschillende ministers kunnen zelf geen initiatief nemen en moeten alle instructies voorgekauwd krijgen. Bovenstaande code is dus zeer slecht. Telkens er zaken binnen het takenpakket van een bepaalde minister wijzigen moet dit ook in de klasse President
aangepast worden.
Dankzij polymorfisme kunnen we dit alles veel mooier oplossen:
We maken abstractie van de taken van alle ministers. We bekijken het dus algemener. We zeggen: "elke minister heeft bepaalde eigen taken en het interesseert ons niet hoe deze worden uitgevoerd."
We verplichten alle adviseurs dat ze overerven van de abstracte klasse
Advisor
die maar 1 abstracte methode heeftAdvise
:
Het leven van de president wordt veel makkelijker:
We kunnen ook nog meer flexibiliteit bieden door één lijst adviseurs op te stellen, zodat er op een bepaald moment meer of minder adviseurs kunnen zijn:
De president moet nu gewoon de juiste adviseurs kunnen kiezen. We kunnen veranderen hoe elk van deze adviseurs zijn taak vervult, zonder de code van President
aan te passen. We kunnen ook makkelijk nieuwe types adviseurs toevoegen (bv. voor landbouw, cyberbeveiliging,...).
Last updated