polymorfie. zdefinitie ypolymorfie = ‘veel vormen’ -> in termen van programmeren : = enkele...

Polymorfie

Polymorfie

Definitie polymorfie = ‘veel vormen’

-> in termen van programmeren : = enkele naam( van een klasse of een methode) verschillende code kan representeren, die door het een of andere

automatische mechanisme wordt geselecteerd => één enkele naam kan veel vormen aannemen => veel verschillende gedragingen uitdrukken

Polymorfie

Definitie veel verschillende gedragingen ook in gewone taal :

vb. openen-> deur openen-> doos openen-> bankrekening openen

Elk object (uit de echte wereld) interpreteert ‘openen’ op eigen manier, maar de actie blijft iets ‘openen’.

polymorfische taal = taal die polymorfie ondersteunt

Polymorfie

Definitie monomorfische taal = taal die geen polymorfie

ondersteunt = taal die alles en iedereen beperkt tot een enkel statisch gedrag, omdat elke naam statisch aan de bijbehorende code is gekoppeld

PolymorfieDefinitie Overerving -> mechanismen voor bepaalde

soorten polymorfie -> voor vervanging geschikte relaties

te vormen = geschiktheid voor inpluggen (pluggability)

belangrijk voor polymorfie: maakt

het mogelijk een specifiek type object op een algemene manier te behandelen

Polymorfie

Definitie voorbeeld: overervingshiërarchie van

PersonalityObject.

Polymorfie

Definitie speak( ) : in PersonalityObject en in alle

subklassen(=> vervangen methode; eigen definitie voor elke subklasse)

noarg constructors

Polymorfie

Definitie

Polymorfie

Definitie

array van PersonalityObject -> elk PersonalityObject vertoont een ander gedrag voor speak( ) => naam PersonalityObject lijkt verschillende gedragingen te vertonen voor speak( )

personalities = polymorfische variabele

Polymorfie

Definitie voorbeeld illustreert mechanisme van

polymorfie idee achter polymorfie -> methode

makeSpeak( )-> methode die

PersonalityObject als argument aanneemt

Polymorfie

Definitie Wegens overerving ->voor vervanging geschikte

relaties => argument van makeSpeak( ) = een instantie van PersonalityObject, of een willekeurige afstammeling daarvan

gespecialiseerde afstammelingen van Personality-Object kunnen gemaakt worden zoals Extro-vertedObject, zonder de methode makeSpeak( ) te veranderen om deze als argument aan te nemen.

Polymorfie

Definitie Polymorfie : wanneer makeSpeak( )

methodeaanroepen uitvoert naar argument -object

juiste methode van het PersonalityObject-

argument wordt aangeroepen gebaseerd op het echte type van de klasse van het argument, in plaats van op het type van de klasse die de methode makeSpeak( ) denkt te gebruiken

Polymorfie

Definitie

als argument van makeSpeak( ) = een ExtrovertedObject

wordt definitie van speak( ) van ExtrovertedObject

aangeroepen en niet de definitie van het PersonalityObject, de basisklasse die als argument aan makeSpeak( ) werd doorgegeven => verschillende meldingen op het scherm afhankelijk van het type van het argument

Polymorfie

Definitie nieuwe functionaliteit toevoegen aan systeem

-> op elk moment-> door nieuwe klassen te laten overerven

van de basisklasse met nieuwe functionaliteit

-> zonder bestaande code te wijzigen

toekomstbestendige software

Polymorfie

Definitie 4 soorten polymorfie:

-> inkapselende polymorfie-> parametrische polymorfie

-> overriding -> overloading

Inkapselende polymorfie

= inclusion polymorphism of 'pure polymorfie’

hierdoor mogelijk gerelateerde objecten op een algemene manier te behandelen

zie begin van dit hoofdstukmethode makeSpeak( )


Analoog voor IntrovertedObject en ExtrovertedObject

PessimisticObject, OptimisticObject, Introver-tedObject en ExtrovertedObject ‘zijn’ allemaal PersonalityObjecten

door vervangbaarheid en inkapselende

polymorfie -> maar één enkele methode voor

alle soorten PersonalityObjecten


Voordelen van inkapselende polymorfie: door vervangbaarheid : willekeurig Personality-

Object aan methode doorgeven

Polymorfie -> methode aanroepen op basis van het echte type van de instantie (OptimisticObject, IntrovertedObject, ExtrovertedObject of PessimisticObject), in plaats van op het schijnbare type (PersonalityObject)


Voordelen van inkapselende polymorfie: minder code schrijven:

->1 methode voor alle typen dan voor elk concreet type een afzonderlijke methode

->makeSpeak( ) kan met elk object werken waarvoor geldt: het object

‘is een’ PersonalityObject. makkelijker nieuwe subtypen toevoegen:

->geen specifieke methode nodig voor elk nieuw type => hergebruik van makeSpeak( )


Voordelen van inkapselende polymorfie: instanties van PersonalityObject lijken veel

verschillende gedragingen vertonen:=> makeSpeak( ): verschillende melding afhankelijk van de invoer van de methode => gedrag van systeem wijzigen door nieuwe klassen te introduceren door gebruik te maken van inkapselende polymorfie=> nieuwe gedrag zonder bestaande code te moeten wijzigen.


Voordelen van inkapselende polymorfie: vermijden van vele controles adhv verschillende

selectiestructuren=> voornaamste doel van overerving is

polymorfisch gedrag mogelijk te maken via voor vervanging geschikte relaties=> hergebruik zal automatisch optreden als op de juiste manier voor vervanging geschikte relaties gedefinieerd worden

Parametrische polymorfie

->algemene methoden en algemene typen =>iets eenmaal coderen, dat met veel verschillende soorten argumenten zal werken

Parametrische methoden = algemene methoden: door het declareren van

parametertypen uit te stellen tot het programma wordt uitgevoerd

bijvoorbeeld: som van twee gehele getallen kan voorgesteld worden door volgende methode:


Parametrische methodenadd(a : geheel getal, b: geheel getal ) : geheel getal

=> argumenten: 2 gehele getallen=> niet mogelijk 2 reële getallen of 2 matrices als argument

add_matrix(a : matrix, b : matrix) : matrixadd_real(a : reëel getal, b: reëel getal ) : reëel getal

voor elk type een eigen add-methode


Parametrische methodenbeter 1 methode dan veel methoden=> meer code=>meer kans op fouten=> moeilijker te onderhoudenbovendien geen natuurlijk model voor add( ):denken in termen van add( ) en niet

add_matrix( )en add_real( ).


Parametrische methoden oplossing met inkapselende polymorfie:

klasse Addable met methode die weet hoe bij een object van deze klasse een andere instantie van addable moet opgeteld worden


Parametrische methodennieuwe methode:add_addable(a : Addable, b: Addable) :

Addable


Parametrische methoden= functiepolymorfie (of function polymorphism)

=> één methode voor optellen:-> maar de methode werkt alleen voor argumenten van het type Addable-> de Addables die aan de methode worden doorgegeven moeten van hetzelfde type zijn

=> methode = foutgevoelig en komt niet overeen met wat er door de interface wordt geïmpliceerd


Parametrische methoden

originele probleem niet opgelostnog methode schrijven voor elk type dat geen Addable is

parametrische polymorfie: één methode voor het optellen van alle typen door uitstellen van het declareren van de typen van de argumenten


Parametrische methodenadd(a : [T], b : [T]) : [T][T] beschouwen als een argument zoals a en bHet argument [T] specificeert het type voor a en b.=> uitstellen van definitie van het type van deargumenten tot het programma wordt uitgevoerd=> a en b hebben hetzelfde type [T]


Parametrische methoden


Parametrische methoden => argumenten moeten nog een specifieke

structuur hebben = een bepaalde methode of een op de juiste manier gedefinieerde operator moet zijn -> hier :elk element moet de bewerking + voor dat type definiëren


Parametrische typen beschouw het ADT van een wachtrij:Queue [T]enqueue([T]) : void // elementen op de wachtrij plaatsendequeue( ) : [T] // elementen van de wachtrij afhalenisEmpty( ) : boolean // controle toestand van de wachtrijpeek( ) : [T] // voorste element bekijken zonder het te

verwijderen

=> geen wachtrijklasse voor elk type dat u in de wachtrij wilt kunnen opnemen, maar dynamisch tijdens het uitvoeren van het programma opgeven welk type elementen men wenst => De Queue is een Queue van een willekeurig type.


Parametrische typen=>om Employees op te slaan: gebruik volgende declaratie :Gegevens: employee_queue : Queue[Employee]

In de main( ): employee_queue = nieuw Queue[Employee]

=> nu alleen instanties van Employee in de wachtrij opnemen met enqueue( ) of daar uit ophalen met dequeue( )


Parametrische typenDoor gebruik van van parameters voorziene typen => maar eenmaal het ADT (wachtrij) schrijven en het dan gebruiken voor het opslaan van alle mogelijke typen

Geen ondersteuning voor van parameters voorziene typen of voor parametrische polymorfie in Java -> er bestaan Java-uitbreidingen voor het ondersteunen van parametrische polymorfie, maar deze zijn niet officieel door Sun goedgekeurd.

Overriding

= manier voor het vervangen van methoden

= belangrijk soort polymorfie vb: speak( ) werd vervangen in elke

subklasse van PersonalityObject vb: de klassen MoodyObject en

HappyObject

Overriding

Overriding

HappyObject vervangt getMood( ) maar niet queryMood( ) dat intern getMood( ) aanroept.=> queryMood( ) = recursieve methode Wordt queryMood( ) van een HappyObject aangeroepen, dan zorgt de instantiepolymorfie ervoor dat de vervangen versie van getMood( ) van HappyObject achter de coulissen wordt aangeroepen.=> geen herdefinitie van queryMood( ) nodig om de juist versie van getMood( ) aan te roepen

Overriding

=> gebruik van abstracte klassen

Overriding

abstracte methoden = uitgestelde methoden (of deferred methods)

-> definitie van de methode wordt overgelaten aan de afgestamde klassen-> abstracte methode kan op dezelfde manier aangeroepen worden als elke andere methode -> Polymorfie zorgt ervoor dat subklassen de juiste versie van de uitgestelde methode aanroepen

Overloading

= ad hoc polymorfie zelfde methodenaam voor verschillende methoden

verschil in• aantal parameters • en type van de parameters

vb: methode max( )+ max(a : geheel getal, b : geheel getal) : geheel getal + max(a : long, b: long ) : long+ max(a : float, b : float) : float+ max(a : double, b : double) : double

Overloading

Overloading is nuttig als een methode onafhankelijk is van zijn argumenten.

methode -> belangrijker dan zijn specifiekeparameters -> van toepassing op veel verschillende

soorten parametersbijv. max( ) -> neemt twee parameters aan en

vertelt welke van de twee het grootst is.

-> definitie is zelfde voor integers , floats, doubles

De bewerking + is een ander voorbeeld van een via overloading vervangen methode. Het idee + is onafhankelijk van zijn argumenten. U kunt allerlei soorten elementen optellen.

Overloading

ander voorbeeld: de bewerking + -> idee + is onafhankelijk van zijn

argumenten: allerlei soorten elementen kunnen opgeteld worden

in geval van geen overloading -> aparte methode, met unieke naam, voor elk type van argument => max( ): * geen abstract idee

* moet gedefinieerd worden in termen van de argumenten* niet meer natuurlijk gemodelleerd

Overloading

+ max_int(a : geheel getal, b : geheel getal) : geheel getal + max_long(a : long, b: long ) : long+ max_float(a : float, b : float) : float+ max_double(a : double, b : double) : double+ max_bird(a : bird, b : bird) : bird

=> geen polymorfisch gedrag -> enkel als dezelfde naam voor verschillende typen kan gebruikt worden; achter coulissen wordt de juiste methode aangeroepen voor het type van argument

Overloading

Dwang = coercion methode lijkt polymorfisch : argument van het

ene type wordt achter de coulissen in het verwachte type omgezet

bijv.:+ add(a : float, b : float) : float

-> twee float-argumenten worden bij elkaar opgeteld

OverloadingDwang

Maak gebruik van 2 integer variabelen(iA en iB) en roep add( ) aan:

iA = 1iB = 2add( iA, iB)

add( ) -> twee float-argumenten -> de compiler zet de int-argumenten in

floats om bij aanroep van add( ) -> voordat ze aan add( ) worden doorgegeven=> conversie (= cast in Java)

Overloading

Dwang=>add( ) lijkt polymorfisch (door dwang):

-> werkt met floats en met ints

Alternatief: add( ) vervangen via overloading:+ add(a : int, b : int) : int

=> add ( iA, iB ) niet door dwang maar juiste methode wordt via overloading

aangeroepen

Effectieve polymorfie

Wordt gegarandeerd door een paar stappen:wordt bereikt door effectieve inkapseling en

overerving zonder inkapseling kan code afhankelijk worden van

implementatie van klassen => er kan geen subklasse meer ingeplugd worden die deze

implementatie herdefinieert opm: publieke interface van een klasse of object

– = beschrijving van welke berichten naar die klasse of dat object kunnen gestuurd worden

– verschilt van de Java-interfaces:


– verschilt van de Java-interfaces: definieert ook welke berichten naar de klasse kunnen gestuurd worden maar in de klasse kunnen nog extra publieke functies gedefinieerd worden

Java-interface publieke interface van klasse of object

– gebruik Java-interfaces om definitie van de interface te scheiden van de

klassenimplementatie – daardoor kunnen eventueel niet aan elkaar gerelateerde klassen dezelfde

interface implementeren– => objecten met een gemeenschappelijke interface kunnen, net als bij

overerving, ook deelnemen in voor vervanging geschikte relaties, zonder deel te hoeven uitmaken van dezelfde overervingshiërarchie.


Overerving = belangrijk voor inkapselende polymorfie wegens de voor vervanging geschikte relatie kan worden aangemoedigd door goed uitgedachte

hiërarchieën:-> Verplaats gemeenschappelijke code naar abstracte klassen -> schrijf objecten die de abstracte klasse

gebruiken ipv van een specifieke, concrete afstammeling daarvan=> elke willekeurige afstammeling kan in programma opgenomen worden


Tips: Volg de tips voor een effectieve inkapseling en

overerving. Programmeer op basis van interface, niet op basis van

de implementatie =>daardoor definieert men welke typen objecten aan het programma mogen deelnemen. De polymorfie zorgt ervoor dat deze objecten op de juiste manier deelnemen.

Denk en programmeer algemeen. -> details overlaten aan de polymorfie=>minder code

Effectieve polymorfieTips:

fundering voor de polymorfie leggen door voor vervanging geschikte relaties op te zetten en te gebruiken=>nieuwe subtypen kunnen toegevoegd worden=>juiste code wordt uitgevoerd bij gebruik van die subtypen

Als interface en de implementatie geheel van elkaar gescheiden kunnen worden =>voorkeur aan dat mechanisme boven overerving

bijv: Java-interface :mogelijk interface zonder implementatie te definiëren en te erven => meer flexibele vervangbaarheid en daardoor meer mogelijkheden voor het gebruiken van polymorfie.


Tips:Gebruik abstracte klassen voor het scheiden van

de interface van de implementatie. Alle klassen die geen eindklassen zijn “moeten” abstract zijn - programmeer alleen op basis van deze abstracte klassen.

polymorfie. zdefinitie ypolymorfie = ‘veel vormen’ -> in termen van programmeren : = enkele...

Documents