Polymorfie Polymorfie z Definitie ypolymorfie veel vormen in

Polymorfie

Polymorfie z. Definitie ypolymorfie = ‘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 z. Definitie yveel 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’. ypolymorfische taal = taal die polymorfie ondersteunt

Polymorfie z. Definitie ymonomorfische 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

Polymorfie z. Definitie y. 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 z. Definitie yvoorbeeld: overervingshiërarchie van Personality. Object.

Polymorfie z. Definitie yspeak( ) : in Personality. Object en in alle subklassen(=> vervangen methode; eigen definitie voor elke subklasse) ynoarg constructors

Polymorfie z. Definitie

Polymorfie z. Definitie

Polymorfie z. Definitie

Polymorfie z. Definitie

Polymorfie z. Definitie

Polymorfie z. Definitie yarray van Personality. Object -> elk Personality. Object vertoont een ander gedrag voor speak( ) => naam Personality. Object lijkt verschillende gedragingen te vertonen voor speak( ) ypersonalities = polymorfische variabele

Polymorfie z. Definitie yvoorbeeld illustreert mechanisme van polymorfie yidee achter polymorfie -> methode make. Speak( ) -> methode die Personality. Object als argument aanneemt

Polymorfie z. Definitie y. Wegens overerving ->voor vervanging geschikte relaties => argument van make. Speak( ) = een instantie van Personality. Object, of een willekeurige afstammeling daarvan gespecialiseerde afstammelingen van Personality. Object kunnen gemaakt worden zoals Extroverted. Object, zonder de methode make. Speak( ) te veranderen om deze als argument aan te nemen.

Polymorfie z. Definitie y. Polymorfie : wanneer make. Speak( ) methodeaanroepen uitvoert naar argument object juiste methode van het Personality. Objectargument 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 make. Speak( ) denkt te gebruiken

Polymorfie z. Definitie als argument van make. Speak( ) = een Extroverted. Object wordt definitie van speak( ) van Extroverted. Object aangeroepen en niet de definitie van het Personality. Object, de basisklasse die als argument aan make. Speak( ) werd doorgegeven => verschillende meldingen op het scherm afhankelijk van het type van het argument

Polymorfie z. Definitie ynieuwe 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 z. Definitie y 4 soorten polymorfie: -> inkapselende polymorfie -> parametrische polymorfie -> overriding -> overloading

Inkapselende polymorfie z= inclusion polymorphism of 'pure polymorfie’ zhierdoor mogelijk gerelateerde objecten op een algemene manier te behandelen zzie begin van dit hoofdstuk zmethode make. Speak( )

Inkapselende polymorfie

Inkapselende polymorfie z. Analoog voor Introverted. Object en Extroverted. Object z. Pessimistic. Object, Optimistic. Object, Introverted. Object en Extroverted. Object ‘zijn’ allemaal Personality. Objecten door vervangbaarheid en inkapselende polymorfie -> maar één enkele methode voor alle soorten Personality. Objecten

Inkapselende polymorfie z. Voordelen van inkapselende polymorfie: ydoor vervangbaarheid : willekeurig Personality. Object aan methode doorgeven Polymorfie -> methode aanroepen op basis van het echte type van de instantie (Optimistic. Object, Introverted. Object, Extroverted. Object of Pessimistic. Object), in plaats van op het schijnbare type (Personality. Object)

Inkapselende polymorfie z. Voordelen van inkapselende polymorfie: yminder code schrijven: ->1 methode voor alle typen dan voor elk concreet type een afzonderlijke methode ->make. Speak( ) kan met elk object werken waarvoor geldt: het object ‘is een’ Personality. Object. ymakkelijker nieuwe subtypen toevoegen: ->geen specifieke methode nodig voor elk nieuw type => hergebruik van make. Speak( )

Inkapselende polymorfie z. Voordelen van inkapselende polymorfie: yinstanties van Personality. Object lijken veel verschillende gedragingen vertonen: => make. Speak( ): 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.

Inkapselende polymorfie z. Voordelen van inkapselende polymorfie: yvermijden van vele controles adhv verschillende selectiestructuren z=> 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 z->algemene methoden en algemene typen =>iets eenmaal coderen, dat met veel verschillende soorten argumenten zal werken z. Parametrische methoden y= algemene methoden: door het declareren van parametertypen uit te stellen tot het programma wordt uitgevoerd ybijvoorbeeld: som van twee gehele getallen kan voorgesteld worden door volgende methode:

Parametrische polymorfie z. Parametrische methoden add(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) : matrix add_real(a : reëel getal, b: reëel getal ) : reëel getal voor elk type een eigen add-methode

Parametrische polymorfie z. Parametrische methoden beter 1 methode dan veel methoden => meer code=>meer kans op fouten => moeilijker te onderhouden bovendien geen natuurlijk model voor add( ): denken in termen van add( ) en niet add_matrix( ) en add_real( ).

Parametrische polymorfie z. Parametrische methoden yoplossing met inkapselende polymorfie: klasse Addable methode die weet hoe bij een object van deze klasse een andere instantie van addable moet opgeteld worden

Parametrische polymorfie z. Parametrische methoden nieuwe methode: add_addable(a : Addable, b: Addable) : Addable

Parametrische polymorfie z. Parametrische methoden = functiepolymorfie (of function polymorphism) y=> éé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 polymorfie z. Parametrische methoden originele probleem niet opgelost nog 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 polymorfie z. Parametrische methoden add(a : [T], b : [T]) : [T] beschouwen als een argument zoals a en b Het argument [T] specificeert het type voor a en b. => uitstellen van definitie van het type van de argumenten tot het programma wordt uitgevoerd => a en b hebben hetzelfde type [T]

Parametrische polymorfie z. Parametrische methoden

Parametrische polymorfie z. Parametrische methoden y=> 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 polymorfie z. Parametrische typen ybeschouw het ADT van een wachtrij: Queue [T] enqueue([T]) : void dequeue( ) : [T] is. Empty( ) : boolean peek( ) : [T] // // elementen op de wachtrij plaatsen elementen van de wachtrij afhalen controle toestand van de wachtrij 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 polymorfie z. 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 polymorfie z. Parametrische typen Door gebruik van parameters voorziene typen => maar eenmaal het ADT (wachtrij) schrijven en het dan gebruiken voor het opslaan van alle mogelijke typen y. 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 z= manier voor het vervangen van methoden z= belangrijk soort polymorfie yvb: speak( ) werd vervangen in elke subklasse van Personality. Object yvb: de klassen Moody. Object en Happy. Object

Overriding

Overriding

Overriding

Overriding Happy. Object vervangt get. Mood( ) maar niet query. Mood( ) dat intern get. Mood( ) aanroept. => query. Mood( ) = recursieve methode Wordt query. Mood( ) van een Happy. Object aangeroepen, dan zorgt de instantiepolymorfie ervoor dat de vervangen versie van get. Mood( ) van Happy. Object achter de coulissen wordt aangeroepen. => geen herdefinitie van query. Mood( ) nodig om de juist versie van get. Mood( ) 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 z= ad hoc polymorfie z zelfde methodenaam voor verschillende methoden verschil in • aantal parameters • en type van de parameters zvb: methode max( ) + + max(a : : geheel getal, b : geheel getal) : geheel getal long, b: long ) : long float, b : float) : float double, b : double) : double

Overloading z. Overloading is nuttig als een methode onafhankelijk is van zijn argumenten. ymethode -> belangrijker dan zijn specifieke parameters -> van toepassing op veel verschillende soorten parameters bijv. max( ) -> neemt twee parameters aan en vertelt welke van de twee het grootst is. -> definitie is zelfde voor integers , floats, doubles

Overloading yander voorbeeld: de bewerking + -> idee + is onafhankelijk van zijn argumenten: allerlei soorten elementen kunnen opgeteld worden yin 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 z. Dwang y= coercion ymethode lijkt polymorfisch : argument van het ene type wordt achter de coulissen in het verwachte type omgezet ybijv. : + add(a : float, b : float) : float -> twee float-argumenten worden bij elkaar opgeteld

Overloading z. Dwang Maak gebruik van 2 integer variabelen(i. A en i. B) en roep add( ) aan: i. A = 1 i. B = 2 add( i. A, i. B) 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 z. Dwang =>add( ) lijkt polymorfisch (door dwang): -> werkt met floats en met ints Alternatief: add( ) vervangen via overloading: + add(a : int, b : int) : int => add ( i. A, i. B ) niet door dwang maar juiste methode wordt via overloading aangeroepen

Effectieve polymorfie Wordt gegarandeerd door een paar stappen: zwordt bereikt door effectieve inkapseling en overerving yzonder inkapseling kan code afhankelijk worden van implementatie van klassen y=> er kan geen subklasse meer ingeplugd worden die deze implementatie herdefinieert yopm: 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:

Effectieve polymorfie – 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.

Effectieve polymorfie y. Overerving = belangrijk voor inkapselende polymorfie wegens de voor vervanging geschikte relatie xkan 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

Effectieve polymorfie z. 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 polymorfie z. Tips: -fundering voor de polymorfie leggen door 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.

Effectieve polymorfie z. 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.