De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

Polymorfie. zDefinitie ypolymorfie = ‘veel vormen’ -> in termen van programmeren : = enkele naam( van een klasse of een methode) verschillende code kan.

Verwante presentaties


Presentatie over: "Polymorfie. zDefinitie ypolymorfie = ‘veel vormen’ -> in termen van programmeren : = enkele naam( van een klasse of een methode) verschillende code kan."— Transcript van de presentatie:

1 Polymorfie

2 zDefinitie 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

3 Polymorfie zDefinitie 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

4 Polymorfie zDefinitie 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

5 Polymorfie zDefinitie yOvererving -> 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

6 Polymorfie zDefinitie yvoorbeeld: overervingshiërarchie van PersonalityObject.

7 Polymorfie zDefinitie yspeak( ) : in PersonalityObject en in alle subklassen(=> vervangen methode; eigen definitie voor elke subklasse) ynoarg constructors

8 Polymorfie zDefinitie

9 Polymorfie zDefinitie

10 Polymorfie zDefinitie

11 Polymorfie zDefinitie

12 Polymorfie zDefinitie

13 Polymorfie zDefinitie yarray van PersonalityObject -> elk PersonalityObject vertoont een ander gedrag voor speak( ) => naam PersonalityObject lijkt verschillende gedragingen te vertonen voor speak( ) ypersonalities = polymorfische variabele

14 Polymorfie zDefinitie yvoorbeeld illustreert mechanisme van polymorfie yidee achter polymorfie -> methode makeSpeak( ) -> methode die PersonalityObject als argument aanneemt

15 Polymorfie zDefinitie yWegens 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.

16 Polymorfie zDefinitie yPolymorfie : 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

17 Polymorfie zDefinitie  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

18 Polymorfie zDefinitie 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

19 Polymorfie zDefinitie y4 soorten polymorfie: -> inkapselende polymorfie -> parametrische polymorfie -> overriding -> overloading

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

21 Inkapselende polymorfie

22 zAnaloog 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

23 Inkapselende polymorfie zVoordelen van inkapselende polymorfie: ydoor 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)

24 Inkapselende polymorfie  Voordelen van inkapselende polymorfie: yminder 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. ymakkelijker nieuwe subtypen toevoegen: ->geen specifieke methode nodig voor elk nieuw type => hergebruik van makeSpeak( )

25 Inkapselende polymorfie  Voordelen van inkapselende polymorfie: yinstanties 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.

26 Inkapselende polymorfie  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

27 Parametrische polymorfie z->algemene methoden en algemene typen =>iets eenmaal coderen, dat met veel verschillende soorten argumenten zal werken zParametrische 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:

28 Parametrische polymorfie zParametrische 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

29 Parametrische polymorfie zParametrische 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( ).

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

31 Parametrische polymorfie zParametrische methoden nieuwe methode: add_addable(a : Addable, b: Addable) : Addable

32 Parametrische polymorfie zParametrische 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

33 Parametrische polymorfie zParametrische 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

34 Parametrische polymorfie zParametrische methoden add(a : [T], b : [T]) : [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]

35 Parametrische polymorfie zParametrische methoden

36 Parametrische polymorfie zParametrische 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

37 Parametrische polymorfie zParametrische typen ybeschouw het ADT van een wachtrij: Queue [T] enqueue([T]) : void // elementen op de wachtrij plaatsen dequeue( ) : [T]// elementen van de wachtrij afhalen isEmpty( ) : boolean// controle toestand van de wachtrij peek( ) : [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.

38 Parametrische polymorfie zParametrische 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( )

39 Parametrische polymorfie zParametrische typen Door gebruik van van parameters voorziene typen => maar eenmaal het ADT (wachtrij) schrijven en het dan gebruiken voor het opslaan van alle mogelijke typen yGeen 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.

40 Overriding z= manier voor het vervangen van methoden z= belangrijk soort polymorfie yvb: speak( ) werd vervangen in elke subklasse van PersonalityObject  vb: de klassen MoodyObject en HappyObject

41 Overriding

42

43

44 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

45 Overriding => gebruik van abstracte klassen

46 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

47 Overloading  = ad hoc polymorfie zzelfde 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 + max(a : long, b: long ) : long + max(a : float, b : float) : float + max(a : double, b : double) : double

48 Overloading zOverloading 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  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.

49 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

50 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

51 Overloading zDwang 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

52 Overloading zDwang Maak gebruik van 2 integer variabelen(iA en iB) en roep add( ) aan: iA = 1 iB = 2 add( 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)

53 Overloading zDwang =>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

54 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:

55 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.

56 Effectieve polymorfie yOvererving = 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

57 Effectieve polymorfie zTips: -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

58 Effectieve polymorfie zTips: -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.

59 Effectieve polymorfie zTips: -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.


Download ppt "Polymorfie. zDefinitie ypolymorfie = ‘veel vormen’ -> in termen van programmeren : = enkele naam( van een klasse of een methode) verschillende code kan."

Verwante presentaties


Ads door Google