Multiple inheritance?

[BassieBulk]

Ik heb b.v. de volgende classes:

Visual Basic .NET:

Public Class Hond
     Private Woef as String
End Class

Public Class Kat
     Private Miauw as String
End Class

Nu wil ik een nieuwe class aanmaken die beide classes inherit:

Visual Basic .NET:

Public Class Dier 
     Inherits Hond
     Inherits Kat
End Class

Met als doel dat ik een object van Dier in 1x kan serializen.
Nu kwam ik al googlend op "Multiple Inheritance" etc.
Maar ik heb het idee dat ik een (elementaire?) denkfout maak.
Gezien ook dat VB.NET dit niet toestaat en alle ingewikkelde constructies
met Interfaces etc. om Multiple Inheritance wel te laten werken.

[The_Ghost16]

Volgens mij moet je
Public Class Hond Inherits Dier doen en niet andersom.

[wackmaniac]

Nu ben ik niet thuis in VB, maar ik denk dat je een denkfout maakt: je wilt namelijk dat Hond en Kat erven van Dier en niet andersom, zoals je hier volgens mij probeert.

[Haan]

Je moet het zo zien: een class die inherit van een andere class is een uitbreiding op de base class. (in bijv. Java is dit ook duidelijker door het 'extends' keyword).

Dit impliceert dus dat de child class meer detail bevat dan de base class, want er wordt iets toegevoegd. Alle classes zitten in een hiërarchie, waarbij classes steeds generieker worden naarmate je hoger in de hiërarchie komt. Ik weet niet of VB ook een class Object heeft, maar in C# en Java is dit de class die helemaal aan de top van de hiërarchie staat. Iedere class erft dus sowieso van Object.

In jouw geval is Dier dus een generieke klasse, en zijn Hond en Kat meer gedetailleerd, ze beschrijven namelijk welk Dier. Daarom erven Hond en Kat van Dier en niet andersom.

[BassieBulk]

Aha! Tot dusver dus een lesje OO

Maar dan rest mij nog een vraagje:
Wat nu als ik een klasse "Hond" de ene keer onder "Dier" wil hangen, m.a.w:
Dier
-->Hond
-->Kat
-->Paard

Visual Basic .NET:

Public Class Hond
     Inherits Dier
     Private Woef as String
End Class

En de andere keer onder b.v. "Huisdier":
Huisdier
-->Hond
-->Kat
-->Vis

Visual Basic .NET:

Public Class Hond
     Inherits Huisdier
     Private Woef as String
End Class

[ Voor 84% gewijzigd door BassieBulk op 03-12-2008 13:44 ]

[Cypher87]

Dan zul je het op deze manier moeten doen:

Dier
-->Huisdier
-->-->Hond
-->-->Kat
-->-->Vis

[BassieBulk]

Duidelijk! En heel logisch eigenlijk... (ik pak nog even de welverdiende hamer d'r bij)

[YopY]

Je zou (om je denkproces nog wat meer te verbeteren) 'inherits' kunnen vervangen door 'is een', dus hond is een huisdier, huisdier is een dier, dier is een ding, etc.

[Verwijderd]

BassieBulk schreef op woensdag 03 december 2008 @ 14:00:
Duidelijk! En heel logisch eigenlijk... (ik pak nog even de welverdiende hamer d'r bij)

Maar, een kat, hond of vis KAN een huisdier zijn, het is niet per definitie een huisdier...
Als je vis altijd een huisdier laat zijn ga je onherroepelijk de fout in als je het over een vis in de sloot zou hebben! Misschien leuk om als extra oefening eens te kijken naar Interfaces

Je hebt het nog steeds over dezelfde diersoort, maar er is iets dat kan varieren, datgene wat varieert zou je eigenlijk buiten de implementatie van je dier moeten houden (Encapsulate what varies op Google). Op die manier bereik je ook een hoger niveau van overzichtelijkheid (classes zijn korter en duidelijker, meer straight to the point), onderhoudbaarheid (datgene wat varieert is op 1 plek ondervangen) en herbruikbaarheid (eenvoudig te implementeren in andere classes die gelijksoortig gebruik nodig hebben).

[ Voor 34% gewijzigd door Verwijderd op 03-12-2008 16:07 ]

[BassieBulk]

Hmm, snap het toch nog niet helemaal.
Ander voorbeeld, ik wil een klasse maken, die alle members heeft die ik opgeef:

Visual Basic .NET:

Public Class Class_1_tm_10
     Public member1 as String
     ....tm....
     Public member10 as String
End Class

Public Class Class_11_tm_20
     Public member11 as String
     ....tm....
     Public member20 as String
End Class

Dan wil ik deze klasse bereiken:

Visual Basic .NET:

Public Class ClassTotaal_1_tm_20
     Public member1 as String
     ....tm....
     Public member20 as String
End Class

Ik dacht dat, zoals in de TS te doen door:

Visual Basic .NET:

Public Class ClassTotaal_1_tm_20
     Inherits Klasse1
     Inherits Klasse2
End Class

Waarbij ik de vrijheid hou, om ook te mogen doen:

Visual Basic .NET:

Public Class ClassTotaal_1_tm_10_plus_999_tm_1000
     Inherits Klasse1
     Inherits Klasse999
End Class

[ Voor 3% gewijzigd door BassieBulk op 03-12-2008 18:00 ]

[Chester]

Je kunt ook gewoon een boolean IsHuisdier oid opnemen in je Dier klasse?

[ Voor 4% gewijzigd door Chester op 03-12-2008 17:59 ]

[Janoz]

BassieBulk schreef op woensdag 03 december 2008 @ 17:52:
Hmm, snap het toch nog niet helemaal.
Ander voorbeeld, ik wil een klasse maken, die alle members heeft die ik opgeef:

Dat is niet een probleem dat je met inheritance op moet lossen, maar met een composite. Zorg dat die 'members1tm10' een property wordt van de class die je die functionaliteit wilt geven.

[Verwijderd]

Chester schreef op woensdag 03 december 2008 @ 17:55:
Je kunt ook gewoon een boolean IsHuisdier oid opnemen in je Dier klasse?

Dat is natuurlijk symptoon bestrijding en het ging me meer om het grotere geheel, dan een (huis)dier an-sich

[BassieBulk]

Janoz schreef op woensdag 03 december 2008 @ 18:05:
[...]

Dat is niet een probleem dat je met inheritance op moet lossen, maar met een composite. Zorg dat die 'members1tm10' een property wordt van de class die je die functionaliteit wilt geven.

Stom, stom, stom
Om het hond-voorbeeld even te pakken, gewoon zo opgelost:

Visual Basic .NET:

Public Class Dier
    Public hond As Hond
    Public kat As Kat
End Class

Als ik nu een object van Hond en Kat aan Dier hang, kan ik alle properties van Hond, en van Kat, bereiken vanuit een object van Dier.

[compufreak88]

BassieBulk schreef op woensdag 03 december 2008 @ 21:28:
[...]

Stom, stom, stom
Om het hond-voorbeeld even te pakken, gewoon zo opgelost:

Visual Basic .NET:

Public Class Dier
    Public hond As Hond
    Public kat As Kat
End Class

Als ik nu een object van Hond en Kat aan Dier hang, kan ik alle properties van Hond, en van Kat, bereiken vanuit een object van Dier.

Dan ga je weer de mist is. Op die manier beschrijf je een heeft-een relatie. Een dier heeft een kat, en een dier heeft een hond. Dat is niet logisch. Ik zou als ik jou was, je nog wat meer inlezen over inheritance en polymorfisme.

[Janoz]

Maar dat is dan juist weer een verkeerde oplossing. Het punt is dat 'Kat' een specialisatie van dier is. Het is dus helemaal niet logisch dat een dier een propertie hond en een property kat heeft....

Waarom zou je methoden op dier aan willen roepen die in kat zitten? Het hele punt is nu juist dat je dier gewoon als dier aan kunt spreken en op de momenten dat je er zeker van bent dat je met een kat te maken hebt dat je dan alsnog ook de methoden en properties van kat op kan vragen.


Om even weer je voorbeeld erbij te pakken. Een propertie als 'woef' is compleet onlogisch. Je zou eerder verwachten dat een dier een methode "maakGeluid" of de property "geluid" heeft en dat deze dan verschillend geimplementeerd is cq een andere waarde heeft voor hond en kat.

[Herko_ter_Horst]

Een paar regels om het makkelijker te maken om te bepalen of inheritance de juiste modellering is:

A. Je denkt dat inheritance de juiste modellering is: gebruik composition.
B. Je weet zeker dat inheritance de oplossing is: gebruik composition.
C. Je weet 100% zeker dat inheritance de juiste modellering is EN een ervaren collega/tweaker is het met je eens: gebruik inheritance.
C1. niet alles wat op het eerste gezicht een IS-A relatie lijkt, is dat ook. Let op verwarring met IS-IN-ROLE.
C2. gebruik geen multiple inheritance
C3. multiple inheritance of implementation is evil
C4. multiple inheritance of type is oppassen

Ad C1: vaak zie je inheritance constructies in de trant van:
Person
-> Employee
-> Customer
Hiermee kom je dan in de problemen als een Employee eens iets wil kopen bij z'n eigen werkgever: die Person is ineens zowel Employee als Customer. Of je komt in de problemen als je ook aan bedrijven wil gaan leveren: Company->Customer... maar je had al Person->Customer.

Dit is dus géén IS-A relatie, maar een IS-IN-ROLE relatie: een Person heeft soms (dus niet de hele tijd) de rol van Employee.

Zelfde met het Dier uit het voorbeeld: een dier kan meerdere rollen vervullen. Huisdier, Lastdier, Trekdier, Slachtvee, etc. Afhankelijk van je UoD kun je er dan voor kiezen een bepaalde rol als een (boolean) property van Dier te modelleren, of expliciet één of meerdere Rollen aan een Dier toe te kennen.