[C#] Multiple inheritance

[Maarten Kroon]

Beste Tweakers,

Ik ben bezig met een Microsoft HoloLens app met Unity3D en C#. Ik loop echter tegen het probleem aan dat ik een klasse heb die van twee andere klassen wil erven (dit kan niet met C#). Ik heb dit geprobeerd op te lossen met interfaces maar dit wil niet echt lukken. Ik heb een vereenvoudigde versie van het probleem in onderstaande beschrijving en klassendiagram geschetst

Ik heb een aantal soorten objecten:

- NetworkObjectManager, singleton klasse met met een lijst van networkobjecten en subklassen daarvan.

- MoveableObject, object welke de gebruiker zelf een plaats kan geven.
- NetworkObject, die niet door de gebruiker verplaatst kan worden maar wel zijn positie via het netwerk naar andere HoloLens brillen stuurt.
- AdvancedNetworkObjecten, zelfde als networkobject maar uitgebreider.

- MoveableNetworkObject, kan de gebruiker zelf verplaatsen en deelt zijn locatie via het netwerk. Hier zit het probleem: deze klasse wil ervan van netwerkobject want de NetworkObjectManager kent alleen netwerkobjecten. Daarnaast wil de klasse ook ervan van MoveableObject want deze klasse bevat een groot deel van de functionaliteit van MoveableNetworkObject.



Wat kan een nette oplossing voor dit probleem dat zou eenvoudig lijkt? Hopelijk kan iemand me hierbij helpen.

EDIT: juiste afbeelding toegevoegd.

[Not Pingu]

Moet NetworkObject perse een concrete class zijn of kun je er ook een interface van maken?

[Maarten Kroon]

Not Pingu schreef op maandag 30 oktober 2017 @ 16:33:
Moet NetworkObject perse een concrete class zijn of kun je er ook een interface van maken?

NetworkObject wil ik het liefste als concrete klasse houden, anders moet ik zijn functies in iedere subklasse opnieuw definiëren of is hier een oplossing voor?

[Gerco]

Ik denk dat dit een case is voor Favor composition over inheritance. Elk object wat je kan zien is een "MovableObject" en elk MovableObject heeft een controller welke ervoor zorgt dat het kan bewegen. Objecten die door de speler gecontroleerd kunnen worden hebben dan een "PlayerController" en objecten die door andere spelers aangestuurd worden krijgen een "NetworkController".

Op die manier koppel je de aansturing los van wat voor soort object het is en heb je dit probleem niet meer.

[ Voor 6% gewijzigd door Gerco op 30-10-2017 19:02 ]

[Maarten Kroon]

Gerco schreef op maandag 30 oktober 2017 @ 17:24:
Ik denk dat dit een case is voor "Favor composition over inheritance". Elk object wat je kan zien is een "MovableObject" en elk MovableObject heeft een controller welke ervoor zorgt dat het kan bewegen. Objecten die door de speler gecontroleerd kunnen worden hebben dan een "PlayerController" en objecten die door andere spelers aangestuurd worden krijgen een "NetworkController".

Op die manier koppel je de aansturing los van wat voor soort object het is en heb je dit probleem niet meer.

Dit is denk ik een goed idee, ik ga ermee aan de slag! Bedankt.

[armageddon_2k1]

Als je met Unity bezig bent heb je misschien ook al gemerkt dat de hele architectuur van Unity ook heel erg gebaseerd is op Composition. Alle GameObject bestaan uit collecties van Components, zoals een MeshRenderer, AudioComponent, Collider, etc.

Niet alleen maakt het het geheel flexibeler, het is ook exact volgens de Unity manier van denken.

[whoami]

Gerco schreef op maandag 30 oktober 2017 @ 17:24:
Ik denk dat dit een case is voor Favor composition over inheritance. Elk object wat je kan zien is een "MovableObject" en elk MovableObject heeft een controller welke ervoor zorgt dat het kan bewegen. Objecten die door de speler gecontroleerd kunnen worden hebben dan een "PlayerController" en objecten die door andere spelers aangestuurd worden krijgen een "NetworkController".

Op die manier koppel je de aansturing los van wat voor soort object het is en heb je dit probleem niet meer.

Vind ik een heel goed voorstel. Hiermee ga je dan meteen ook nog eens je class-structuur heel wat vereenvoudigen.

Wat voor mij nog een doorn in het oog zou zijn, is die NetworkObjectManager. Wat is die zijn functie precies ?

Het lijkt me ook dat ieder MoveableObject zijn positie moet kunnen delen via het netwerk, ongeacht of het object nu wel of niet door de speler kan aangestuurd worden ?

[Maarten Kroon]

whoami schreef op maandag 30 oktober 2017 @ 20:20:
[...]

Wat voor mij nog een doorn in het oog zou zijn, is die NetworkObjectManager. Wat is die zijn functie precies ?

Het lijkt me ook dat ieder MoveableObject zijn positie moet kunnen delen via het netwerk, ongeacht of het object nu wel of niet door de speler kan aangestuurd worden ?

De HoloLens brillen versturen hun berichten via een byte stream over het netwerk. De NetworkObjectManager ontvangt de berichten en stuurt deze door naar het juiste object.

Niet ieder MoveableObject moet zijn positie kunnen delen via het netwerk, de app bevat ook objecten die verplaatst kunnen worden maar die hun positie niet via het netwerk mogen delen.

[Maarten Kroon]

Gerco schreef op maandag 30 oktober 2017 @ 17:24:
Ik denk dat dit een case is voor Favor composition over inheritance.

Probleem is nu opgelost door ieder object dat verplaatst moet worden een MoveableObject aan te laten maken en niet meer te erven van de klasse.