De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

Overerving. zverband tussen objecten in OOP -> object kan een ander object gebruiken via berichten, dankzij goede toepassing van inkapseling => goed gedefinieerde.

Verwante presentaties


Presentatie over: "Overerving. zverband tussen objecten in OOP -> object kan een ander object gebruiken via berichten, dankzij goede toepassing van inkapseling => goed gedefinieerde."— Transcript van de presentatie:

1 Overerving

2 zverband 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 zvoorbeeld: de overerving van Employee

4 Overerving zUML-voorstelling van de klasse Employee

5 Overerving

6

7

8 -> 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 zOplossingen: -> 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

14

15 *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  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 zwanneer 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 zovererving niet enkel voor hebzuchtig hergebruik overervingsrelaties moeten zinvol zijn zoverervingshiërarchie -> voorstelling door middel van boomstructuur -> = verbindingsdiagram : toont de relaties tussen klassen als gevolg van overerving

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

23 Overerving : zChild-klasse = subklasse erft rechtstreeks van parent- klasse = superklasse zovererving = “is een”-relatie y=>subklasse erft alle eigenschappen en gedragingen van superklasse, eventueel zelf geërfd van andere klassen y=> 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 : zChild-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 : zechter meestal: child -> 1 parent ( in Java) zwanneer meer dan één parent => meervoudige overerving (of multiple inheritance) (niet in Java) zChild-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: zEen 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: zEen 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

31

32

33

34

35

36 Alle soorten methoden worden gedemonstreerd: zVervangen ymethode: toString( ) zNieuwe ymethoden: getZCoordinate( ); setZCoordinate( ) yattribuut: z_coord zRecursieve ymethoden: getXCoordinate( ); setXCoordinate( ) getYCoordinate( ); setYCoordinate( ) yattribuut: x_coord; y_coord

37 Mechanisme van overerving: zVervangen y= overriding; = herdefiniëren van een methode = child neemt een methode uit parent en herschrijft deze om het gedrag van de methode te wijzigen. yThreeDimensionalPoint 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: zVervangen  toString ( ) in ThreeDimensionalPoint : -> identificeert de instantie als een driedimensionaal punt en drukt de 3 onderdelen af waaruit de coördinaat bestaat ybeschouw volgende main:

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

40 Mechanisme van overerving: zVervangen yresultaat 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: zVervangen  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: zVervangen -> 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: zVervangen

44 Mechanisme van overerving: zVervangen yniet 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: zVervangen yBeveiligde -> enkel toegang voor klasse en voor subklassen xniet publiek maken: alleen zij die een uitgebreide kennis van de klasse hebben mogen beveiligde methoden en attributen gebruiken. yprivé -> alleen voor de klasse zelf bedoeld xprivé = geen enkel ander object dan het object zelf de methode kan aanroepen xprivé-methoden niet beveiligd maken omdat een subklasse er misschien ooit toegang toe zal willen hebben.

46 Mechanisme van overerving: zVervangen  xGebruik 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: zVervangen x= 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 xbijwerken = normaal want echte objectgeoriënteerde programmeren is een stapsgewijs proces xvuistregel = 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: zVervangen => 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: zVervangen ygevolg: alleen beveiligde en publieke methoden en attributen zijn het belangrijkst voor de overerving ykan 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: zNieuwe methoden en attributen ykomen enkel in child, voor niet in parent y=> nieuwe functionaliteit toevoegen aan interface van child zRecursieve methoden en attributen ywordt gedefinieerd in parent of andere voorouder maar niet in child ybericht wordt door de hiërarchie omhoog doorgegeven tot definitie van de methode wordt gevonden -> zie vroeger

51 Soorten overerving: z3 manieren waarop overerving kan gebruikt worden: y1.voor het hergebruiken van implementatie; y2.voor het verschil; y3.voor typevervanging. zWees gewaarschuwd, sommige soorten hergebruik zijn meer wenselijk dan andere! Laten we elk van deze gebruiksdoelen eens in detail bekijken.

52 Soorten overerving: zOvererving voor implementatie ydoor overerving komt code uit parent automatisch beschikbaar voor child => niet nodig code te kopiëren en plakken ymen zit echter vast aan de overgeërfde implementatie -> eventueel ook negatieve effecten => vervangen van de beveiligde methoden kan de invloed op een slechte of ontoepasselijke implementatie verminderen

53 Soorten overerving: zOvererving voor implementatie y= zwakste vorm van overerving => child krijgt automatisch het type van de parent  het op de juiste manier erven van het type moet altijd voorrang hebben tijdens het ontwerpen van klassenhiërarchieën ywe beschouwen een eenvoudige definitie van overerving: bij overerving wordt zowel de implementatie als de interface overgeërfd -> in sommige objectgeoriënteerde talen gaat dit apart

54 Soorten overerving: zOvererving voor het verschil  programmeren op het verschil -> enkel code wordt toegevoegd die de nieuwe klasse van de geërfde klasse laat verschillen ygezien in voorbeeld met TwoDimensionalPoint en ThreeDimensionalPoint ; ook in Employee. yThreeDimensionalPoint verschilt van parent door -> Z-coördinaat wordt toegevoegd -> 2 nieuwe ondersteunende methoden voor de Z- coördinaat voor het instellen en ophalen van deze eigenschap -> herdefinitie van de methode toString( )

55 Soorten overerving: zOvererving voor het verschil ydaardoor stapsgewijs programmeren mogelijk ykleinere, beter beheersbare code => eenvoudiger ontwerpen => minder fouten ytwee manieren van programmeren op verschil via overerving: -> door nieuwe gedragingen en eigenschappen toe te voegen ->door oude gedragingen en eigenschappen te herdefiniëren.

56 Soorten overerving: zOvererving voor het verschil  beide gevallen staan bekend als specialisatie yspecialisatie = het proces van een child-klasse die zichzelf definieert in termen van hoe deze van zijn parent verschilt door -> nieuwe methoden en eigenschappen toe te voegen -> herdefinitie bestaande methoden -> verwijderen methoden is onmogelijk

57 Soorten overerving: zOvererving voor het verschil  een klasse kan niet selectief erven Specialisatie beperkt wat er wel en wat niet een driedimensionale punt kan zijn: een Three-DimensionalPoint kan altijd een TwoDimensional-Point zijn, maar een TwoDimensionalPoint kan nooit een ThreeDimensionalPoint zijn  ThreeDimensionalPoint = specialisatie van TwoDimensionalPoint TwoDimensionalPoint = generalisatie van ThreeDimensionalPoint.

58 Soorten overerving: zOvererving voor het verschil yverschil tussen generalisatie en specialisatie: bij specialiseren -> omlaag door hiërarchie bewegen bij generaliseren -> omhoog door hiërarchie bewegen

59 Soorten overerving: zOvererving voor het verschil yspecialiseren = niet beperken van de functionaliteit = beperken van het aantal typecategorieën ymen kan ingewikkelde ingewikkelde structuren van klassenhiërarchieën maken -> streven naar ondiepe hiërarchieën -> diepgaande hiërarchieën zijn moeilijker te onderhouden

60 Soorten overerving: zOvererving voor het verschil yvoorouder = klasse die in de klassenhiërarchie vóór de parent van een gegeven child komt bijv. : Format een voorouder van DecimalFormat. yafstammeling = klasse die na een andere gegeven klasse in de klassenhiërarchie voorkomt bijv.: DecimalFormat is afstammeling van Format. yhoofdklasse (of root ) = de bovenste klasse in de overervingshiërarchie. bijv.: OneDimensionalPoint = een hoofdklasse

61 Soorten overerving: zOvererving voor het verschil yeindklasse (of leaf-klasse) = een klasse zonder children bijv.: DecimalFormat

62 Soorten overerving: zOvererving voor het verschil

63 Soorten overerving: zOvererving voor het verschil yopmerking 1: -> afstammelingen weerspiegelen de in hun voorouders gemaakte wijzigingen bijv.: er is een fout in TwoDimensionalPoint => alle klassen van ThreeDimensionalPoint tot aan FourDimensionalPoint zullen van de wijziging profiteren als u de fout in TwoDimensionalPoint verhelpt verhelpen van fouten of efficiënter maken van implementatie => alle afgestamde klassen in de hiërarchie hebben daar voordeel van

64 Soorten overerving: zOvererving voor het verschil yopmerking 2: -> tot dusver alleen enkelvoudige overerving -> meervoudige overerving = een enkel object kan rechtstreeks van meer dan één andere klasse erven Meervoudige overerving = controversieel aspect van het objectgeoriënteerd programmeren: * sommigen beweren dat meervoudige overerving software alleen maar moeilijker te begrijpen, te ontwerpen en te onderhouden maakt * Anderen zweren erbij en beweren dat een taal zonder meervoudige overerving niet compleet is

65 Soorten overerving: zOvererving voor het verschil yopmerking 2: -> meervoudige overerving kan nuttig zijn, mits er voorzichtig en op de juiste manier gebruik van wordt gemaakt -> meervoudige overerving introduceert een aantal problemen. Een volledige bespreking van de voor- en nadelen van meervoudige overerving valt echter buiten het bestek van deze cursus.

66 Soorten overerving: zOvererving voor typevervanging ydaardoor kunnen voor vervanging geschikte relaties gemaakt worden yvoorbeeld van een voor vervanging geschikte relatie: klasse Line

67 Soorten overerving: zOvererving voor typevervanging

68 Soorten overerving: zOvererving voor typevervanging

69 Soorten overerving: zOvererving voor typevervanging

70 Soorten overerving: zOvererving voor typevervanging

71 Soorten overerving: zOvererving voor typevervanging

72 Soorten overerving: zOvererving voor typevervanging yEen voor vervanging geschikte relatie betekent dat elk willekeurig object dat van een TwoDimensionalPoint erft aan de constructor van Line kan doorgegeven worden. Reden: -> de “is een”-relatie een child “is een” parent ThreeDimensionalPoint 'is' een TwoDimensionalPoint.

73 Soorten overerving: zOvererving voor typevervanging

74 Soorten overerving: zOvererving voor typevervanging yaan de constructor van de lijn wordt zowel een TwoDimensionalPoint als een ThreeDimensional- Point doorgegeven yresultaat van deze main Midpoint : (14.0, 14.0) Distance :

75 Soorten overerving: zOvererving voor typevervanging yEen voor vervanging geschikte relatie = geschiktheid voor inpluggen (pluggability) -> elk bericht dat naar parent kan gestuurd worden kan ook naar een child ervan gestuurd worden => child kan behandeld worden als zou deze uitwisselbaar zijn met zijn parent => daarom nooit gedragingen verwijderen tijdens het maken van een child

76 Soorten overerving: zOvererving voor typevervanging yGeschiktheid voor inpluggen ->nieuwe subtypen maken: als programma weet hoe het een voorouder moet gebruiken, dan weet het ook hoe het de nieuwe objecten moet gebruiken => programma hoeft het precieze type van het object niet te kennen => programma kan object gebruiken, zolang dat object maar een voor vervanging geschikte relatie tot het verwachte type heeft.

77 Soorten overerving: zOvererving voor typevervanging yEen voor vervanging geschikte relatie : enkel in de zin van de specialisaties => neerwaarts en niet opwaarts -> methode met als argument een bepaald type van een object => geen parent ipv het object; wel alle afstammelingen zijn geschikt.

78 Soorten overerving: zOvererving voor typevervanging -> bijvoorbeeld de constructor van Line: + Line(cp1: TwoDimensionalPoint, cp2 : TwoDimensionalPoint) * TwoDimensionalPoint of een willekeurige afstammeling van TwoDimensionalPoint kan aan constructor worden doorgeven. * maar geen OneDimensionalPoint staat hoger in de klassenhiërarchie dan TwoDimensionalPoint

79 Soorten overerving: zOvererving voor typevervanging yEen subtype = een type dat een ander type uitbreidt via overerving. yGeschiktheid voor inpluggen vergroot de kans op hergebruik: -> vb: u schrijft een array van TwoDimensionalPoint's => array ook voor elke willekeurige afstammeling van TwoDimensionalPoint !  Geschiktheid voor inpluggen is belangrijk, want hiermee kunt u algemene code schrijven. U kunt gewoon objecten schrijven die met objecten van het type TwoDimensionalpoint kunnen omgaan, in plaats van een aantal meervoudige ALS-structuren (case in Java) of ALS-DAN -controles te moeten schrijven om te zien wat voor soort objecten er momenteel in het programma worden gebruikt.

80 Soorten overerving: zOvererving voor typevervanging yGeschiktheid voor inpluggen: belangrijk -> objecten schrijven die met objecten van het type TwoDimensionalpoint kunnen omgaan ipv meervoudige ALS-structuren (case in Java) of ALS-DAN-controles

81 Tips voor effectieve overerving: zOp een juiste manier gebruik maken van overerving ygebruik altijd de “is een” -regel xovererving voor hergebruik van interfaces en voor het definiëren van voor vervanging geschikte relaties xvoor het uitbreiden van een implementatie -> alleen als voldaan is aan de “is-een”-test xhergebruik van implementatie -> in eenvoudige gevallen: samenstelling gebruiken alleen overerving als de 'is een'-test op de resulterende hiërarchie kan toegepast worden

82 Tips voor effectieve overerving: zGoede overervingshiërarchieën yofwel hiërarchieën ontdekken terwijl u werkt -> herschrijf dan uw code yofwel hiërarchieën weloverwogen ontwerpen =>  te volgen ontwerpprincipes -vuistregel: klassenhiërarchieën -> relatief ondiep -verplaats algemene dingen naar abstracte basisklassen

83 Tips voor effectieve overerving: Abstracte basisklassen: ->mogelijk methodes zonder implementatie te specificeren ->geen instanties mogelijk wegens eventueel ontbreken van implementatie ->abstractiemechanisme dwingt ervende klasse implementatie te leveren -> = nuttig voor geplande overerving: helpen ontwikkelaar zien wat moet geïmplementeerd worden

84 Tips voor effectieve overerving: Abstracte basisklassen: ->als taal geen abstractiemechanisme levert  lege methoden maken en documenteren dat die methoden in hun geheel door subklassen moeten worden geïmplementeerd. -gemeenschappelijke code in klassen => geen zin  gemeenschappelijke code verwijderen en naar één enkele parent-klasse verplaatsen niet te ver omhoog in hiërarchie, alleen naar het eerstvolgende niveau boven het beschouwde niveau

85 Tips voor effectieve overerving: -refactoring : -> moeilijk op voorhand hiërarchieën in hun geheel te plannen -> gemeenschappelijkheden zullen pas opvallen als dezelfde code een paar maal is geschreven  herschrijven van klassen als gemeenschappelijk- heid opmerkt wordt = refactoring

86 Tips voor effectieve overerving: zGoede inkapseling van parent en child yGebruik goed gedefinieerde interfaces tussen de parent en de child, zoals tussen andere klassen yMethoden die specifiek bedoeld zijn voor gebruik door subklassen, worden beveiligd (protected) gemaakt, zodat alleen de subklasse ze kan zien. Daardoor krijgen de subklassen wat meer controle, zonder deze controle voor elke klasse beschikbaar te maken.

87 Tips voor effectieve overerving: zGoede inkapseling van parent en child yinterne implementatie van uw objecten mag niet voor subklassen open gesteld worden, anders wordt subklasse afhankelijk van die implementatie.  Afsluitende tips voor effectieve overerving: yvervanging = voornaamste doel van overerving -> als een object 'intuïtief' in een hiërarchie lijkt thuis te horen, daarom is dit niet noodzakelijk zo en daarom moet u het ook werkelijk niet doen.

88 Tips voor effectieve overerving:  Afsluitende tips voor effectieve overerving:  Programmeer op verschil om code hanteerbaar te houden.  Geef altijd de voorkeur aan samenstelling boven overerving voor het hergebruiken van implementatie =>de betrokken klassen kunnen makkelijker gewijzigd worden.


Download ppt "Overerving. zverband tussen objecten in OOP -> object kan een ander object gebruiken via berichten, dankzij goede toepassing van inkapseling => goed gedefinieerde."

Verwante presentaties


Ads door Google