Overerving

1. Overerving

2. Overerving • verband tussen objecten in OOP -> object kan een ander object gebruiken via berichten, dankzij goede toepassing van inkapseling => goed gedefinieerde opzichzelfstaande objecten. -> overerving: definitie van nieuwe klasse wordt gebaseerd op een bestaande klasse => nieuwe klasse erft alle eigenschappen en gedragingen van bestaande klasse

3. Overerving => alle methoden en eigenschappen uit de bestaande klasse zitten automatisch in de interface van de nieuwe klasse bestaan • voorbeeld: de overerving van Employee

4. Overerving • UML-voorstelling van de klasse Employee

5. Overerving

6. Overerving

7. Overerving

8. Overerving -> gebruik in loonlijsten bijvoorbeeld -> nu werknemer modelleren die op basis van commissie werkt: CommissionWorker * heeft een basisloon * plus een commissie per verkoop -> afgezien van deze vereiste is CommissionWorker precies hetzelfde als een Employee -> CommissionWorker “is een” Employee.

9. Overerving • Oplossingen: -> met inkapseling: * code uit Employee herhalen * nieuwe code voor commissie en berekenen loon toevoegen * 2x zelfde basiscode : bij fout op 2 plaatsen wijzigingen doorvoeren * niet aan te raden

10. Overerving -> werknemervariabele in de klasse CommissionWorker opnemen : * alle berichten zoals getLastName( ) en getFirstName( ) aan de instantie van Employee delegeren = proces waarbij een object een bericht aan een ander object doorgeeft om aan een aanvraag te voldoen * herdefinitie van alle methoden in Employee is nodig om alle berichten te kunnen doorgeven => geen optie

11. Overerving -> overerving:

12. Overerving

13. Overerving

14. Overerving

15. Overerving *super: verwijzing naar basisklasse : in casu klasse Employee *CommissionWorker erft van Employee : toString( ), getFirstName ( ), getLastName ( ), setFirstName ( ), setLastName ( ), firstName en lastName maken deel uit van de definitie. => publieke interface van Employee wordt een onderdeel van interface van CommissionWorker

16. Overerving =>elk bericht naar Employee kan ook naar CommissionWorker gestuurd worden dit gebeurt in de volgende main( ) met als resultaat: First Name: Mr Last Name: Sales Total Pay: $10.5

17. Overerving

18. Overerving • Doel van overerving: -> overerving omvat meer dan alleen gewoon het erven van een publieke interface en een implementatie : dus hergebruik -> herdefinitie van elk gedrag dat u niet bevalt: bijvoorbeeld: toString( ) => software aanpassen als eisen veranderen: * maak nieuwe klasse die oude functionaliteit erft

19. Overerving * vervang functionaliteit die gewijzigd moet worden -> overriding * of voeg de ontbrekende functionaliteit toe -> voordeel van overriding: werkwijze van een object kan veranderd worden zonder de originele klassedefinitie te veranderen => goed geteste, gevalideerde basiscode kan intact gelaten worden. Zelfs mogelijk als originele broncode van een klasse niet beschikbaar is

20. Overerving: -> ander belangrijk gebruiksdoel: * een klasse groepeert gerelateerde objecten * Overerving maakt het mogelijk gerelateerde klassen te groeperen en te classificeren • wanneer overerving gebruiken voor hergebruik: -> “is een”-regel: een CommissionWorker is een Employee

21. Overerving: -> mislukt deze regel gebruik dan “bevat een”- regel: beschrijft de relatie waarbij de ene klasse een instantie van een andere klasse bevat-> aggregatie • overerving niet enkel voor hebzuchtig hergebruik overervingsrelaties moeten zinvol zijn • overervingshiërarchie -> voorstelling door middel van boomstructuur -> = verbindingsdiagram : toont de relaties tussen klassen als gevolg van overerving

22. Overerving: • Eenvoudigste overervingshiërarchie -> child(kind)-parent(ouder)-relatie -> start van elke overervingshiërarchie -> UML-voorstelling : pijl in de zin van de parent -> vb:

23. Overerving: • Child-klasse = subklasse erft rechtstreeks van parent- klasse = superklasse • overerving = “is een”-relatie • =>subklasse erft alle eigenschappen en gedragingen van superklasse, eventueel zelf geërfd van andere klassen • => alles wat u met parent kunt doen, kunt u ook met child => dan pas is overervingshiërarchie zinvol ; daarop controleert “is een”- test

24. Overerving: • Child-klasse -> alleen functionaliteit uitbreiden en toevoegen -> nooit functionaliteit verwijderen => als dit nodig is => child voor parent in overervingshiërarchie • Parent-klassen en children-klassen lijken op elkaar als echte ouders en kinderen. Klassen delen type-informatie, in plaats van genen.

25. Overerving: • echter meestal: child -> 1 parent ( in Java) • wanneer meer dan één parent => meervoudige overerving (of multiple inheritance) (niet in Java) • Child-klassen : gedragingen wijzigen: 2 manieren:

26. Overerving: 2 manieren: 1. nieuwe methodes en eigenschappen toevoegen bijv: kind : piano spelen en ouder niet 2. Herdefiniëren van geërfd gedrag door een oude methode te herschrijven bijv: ouders slecht in wiskunde; kind niet door extra te studeren

27. Mechanisme van overerving: • Een via overerving geconstrueerde klasse erft -> implementatie -> gedragingen -> eigenschappen(attributen) van parent => alle methoden en attributen in interface van parent => ook in interface van child  interface parent  interface child

28. Mechanisme van overerving: • Een via overerving geconstrueerde klasse kan 3 belangrijke soorten methoden en attributen hebben: • Vervangen - De nieuwe klasse erft de methode of ? attribuut ? van de parent, maar levert een nieuwe definitie. • Nieuw - De nieuwe klasse voegt een geheel nieuwe methode of attribuut toe. • Recursief - De nieuwe klasse erft simpelweg een methode of attribuut van de parent.

29. Mechanisme van overerving:

30. Mechanisme van overerving:

31. Mechanisme van overerving:

32. Mechanisme van overerving:

33. Mechanisme van overerving:

34. Mechanisme van overerving:

35. Mechanisme van overerving:

36. Mechanisme van overerving: Alle soorten methoden worden gedemonstreerd: • Vervangen • methode: toString( ) • Nieuwe • methoden: getZCoordinate( ); setZCoordinate( ) • attribuut: z_coord • Recursieve • methoden: getXCoordinate( ); setXCoordinate( ) getYCoordinate( ); setYCoordinate( ) • attribuut: x_coord; y_coord

37. Mechanisme van overerving: • Vervangen • = overriding; = herdefiniëren van een methode =child neemt een methode uit parent en herschrijft deze om het gedrag van de methode te wijzigen. • ThreeDimensionalPoint herdefinieert de methode toString ( ) uit TwoDimensionalPoint • toString ( )in TwoDimensionalPoint : -> identificeert de instantie als een tweedimen- sionaal punt en drukt de twee onderdelen af waaruit de coördinaat bestaat

38. Mechanisme van overerving: • Vervangen • toString ( )in ThreeDimensionalPoint : -> identificeert de instantie als een driedimensionaal punt en drukt de 3 onderdelen af waaruit de coördinaat bestaat • beschouw volgende main:

39. Mechanisme van overerving: • Vervangen • toString ( )in ThreeDimensionalPoint : -> identificeert de instantie als een driedimensionale punt en drukt de 3 onderdelen af waaruit de coördinaat bestaat • beschouw volgende main:

40. Mechanisme van overerving: • Vervangen • resultaat van de main: I am a 2 dimensional point. My x coordinate is: 1 My y coordinate is: 2 I am a 3 dimensional point. My x coordinate is: 1 My y coordinate is: 2 My z coordinate is: 3

41. Mechanisme van overerving: • Vervangen • Maar hoe weet het object nu welke definitie het moet gebruiken? -> antwoord = afhankelijk van onderliggende OO- implementatie, nl. OO-systemen zoeken: 1. definitie in object waar bericht is aan door- gegeven 2. daar -> geen definitie => hoger in hiërarchie kijken tot een definitie wordt gevonden.

42. Mechanisme van overerving: • Vervangen -> dit is de manier waarop een bericht wordt verwerkt en dit is de reden waarom overerving werkt => 1. wordt definitie van de child aangeroepen omdat dit de eerste definitie is die wordt gevonden 2. daar -> geen definitie => hoger in hiërarchie zoeken tot een definitie wordt gevonden.

43. Mechanisme van overerving: • Vervangen

44. Mechanisme van overerving: • Vervangen • niet alle methoden en attributen kunnen door child vervangen worden -> afhankelijk van toegangscontrole adhv sleutelwoorden 1. Privé : toegang is beperkt tot de klasse zelf 2. Protected - Beveiligd: toegang is beperkt tot de klasse en children daarvan 3. Public - Publiek: toegang wordt toegestaan aan iedereen

45. Mechanisme van overerving: • Vervangen • Beveiligde -> enkel toegang voor klasse en voor subklassen • niet publiek maken: alleen zij die een uitgebreide kennis van de klasse hebben mogen beveiligde methoden en attributen gebruiken. • privé -> alleen voor de klasse zelf bedoeld • privé = geen enkel ander object dan het object zelf de methode kan aanroepen • privé-methoden niet beveiligd maken omdat een subklasse er misschien ooit toegang toe zal willen hebben.

46. Mechanisme van overerving: • Vervangen  • Gebruik beveiligd alleen voor die methoden waarvan u weet dat een subklasse deze wil gebruiken; anders privé of publiek  strenge werkwijze => daardoor later misschien naar code teruggaan om toegangsniveau van een methode te wijzigen. Deze werkwijze leidt echter tot een strakker ontwerp dan een werkwijze die alles voor een subklasse openstelt.

47. Mechanisme van overerving: • Vervangen • = geen slechte werkwijze (terugkeren en bijwerken van toegangsniveau) maar overervingshiërarchieën mogen nooit per ongeluk optreden: hiërarchieën moeten zich op een natuurlijke manier ontwikkelen tijdens programmatie • bijwerken = normaal want echte objectgeoriënteerde programmeren is een stapsgewijs proces • vuistregel = alles privé te maken => soms geen voordeel => afhankelijk van wat u aan het programmeren bent: bijvoorbeeld bibliotheken met algemene klassen om te verkopen-> standaard beveiligd.

48. Mechanisme van overerving: • Vervangen => afhankelijk van wat u aan het programmeren bent: bijvoorbeeld bibliotheken met algemene klassen om te verkopen-> standaard beveiligd  klanten kunnen overerving gebruiken voor het uitbreiden van klassen. ook subklassen ontwerpen met overerving in gedachten  overervingsprotocol = abstracte structuur alleen zichtbaar via beveiligde elementen van klasse

49. Mechanisme van overerving: • Vervangen • gevolg: alleen beveiligde en publieke methoden en attributen zijn het belangrijkst voor de overerving • kan zich recursief gedragen: de vervangen methode in de child kan de versie van de methode uit de parent aanroepen =>mogelijkheid om versie van de superklasse te gebruiken terwijl nieuw gedrag in subklasse wordt gedefinieerd -> gebruik van sleutelwoord super

50. Mechanisme van overerving: • Nieuwe methoden en attributen • komen enkel in child, voor niet in parent • => nieuwe functionaliteit toevoegen aan interface van child • Recursieve methoden en attributen • wordt gedefinieerd in parent of andere voorouder maar niet in child • bericht wordt door de hiërarchie omhoog doorgegeven tot definitie van de methode wordt gevonden -> zie vroeger