[C++] Pointer return probleem

[Hu9o]

Hallo allemaal,

In een project heb ik een methode van een object een pointer moet returnen. Het type van de pointer kan van 3 soorten zijn (het is 1 pointer die terug gaat). Hierdoor dacht ik het op te lossen doormiddel van een functionoverload, maar het probleem is dat er geen argumenten mee gestuurd worden waar door er onderscheid gemaakt kan worden voor de compiler.

De vraag is dus eigelijk:

Is het ook mogelijk om een type te maken waarin een van de 3 pointers past? En dan zo dat er achteraf nog nagegaan kan worden welk type het is.

[ Voor 3% gewijzigd door Hu9o op 09-02-2004 10:35 ]

[curry684]

Union met info-variabele.

Volgens mij wil je echter gewoon een goed inheritancemodel maja.

[ Voor 58% gewijzigd door curry684 op 09-02-2004 10:34 ]

[WildernessChild]

1. Een object kan niets returnen.
2. Je kunt geen overloading gebruiken waarbij het return type verschilt.
3. (er van uitgaande dat ik het probleem begrijp) Wat is het bezwaar om gewoon 3 verschillende functies te maken, als ze toch iets verschillends opleveren?

[Hu9o]

Ik ga even kijken naar die union.

en @ wildernis:
1 geedit
2 daar kwam ik ook achter
3 Het probleem is dat er van te voren niet bekend is van welk type de pointer is. Er is dus 1 methode die aangeroepen wordt welke 1 vd 3 pointers teruggeeft.

[curry684]

Maar dan zijn het toch related types mag ik hopen en is het dus geen probleem om een common base te geven?

[whoami]

Hu9o schreef op 09 februari 2004 @ 10:32:
Is het ook mogelijk om een type te maken waarin een van de 3 pointers past? En dan zo dat er achteraf nog nagegaan kan worden welk type het is.

Als alle 3 die types van dezelfde base class overerven, is er toch geen probleem? Dan kan je die base class gebruiken als return type. Die 3 types zijn dan nl. ook van het type v/d base class.

[Hu9o]

Hmm, zeggen jullie nu dat ik de pointer kan wijzen naar de superclass?

Het zit namelijk zo:
Item is de hoofdklasse en er zijn drie objecten uit overgeërfd. CD, DVD en CD-ROM.

Nu moet er dus een pointer naar 1 vd drie CD's gereturnd worden. Maar kan deze pointer ook van het type Item zijn:?

[WildernessChild]

Ja, dat kan

Edit: laat ik het iets duidelijker maken: dit is juist het hele idee van inheritance. Misschien een idee om eens een goed boek over OO aan te schaffen?

[ Voor 85% gewijzigd door WildernessChild op 09-02-2004 10:59 ]

[curry684]

Da's het hele idee van inheritance en zo

[Janoz]

Dat is de hele essentie van object georienteerd programeren . Wat je eventueel nog zou kunnen doen is een tussenliggende klasse die aangeeft dat het een verwisselbaar medium is (eventueel readonly oid). Dan heb je alle drie klassen namelijk mooi samengenomen.

[Hu9o]

Ok bedankt allemaal

Ik kan het nog niet testen, omdat die item klassen nog niet af zijn.

[whoami]

curry684 schreef op 09 februari 2004 @ 10:59:
Da's het hele idee van inheritance en zo

Sterker zelfs. Ik zou durven stellen dat het het één van de ideeën achter OO is. Op die manier doe je nl. aan 'data hiding', en maak je polymorphisme mogelijk.
Je verbergt nl. welk type je nu uiteindelijk doorgeeft.

[curry684]

Ik vind trouwens DVD inheriten van item niet echt een toonbeeld van een goed classmodel. In welke class ga je nu eigenlijk dingen als 'Capacity' en 'FreeSpace' opslaan?

* curry684 gaat even educatief verantwoord bezig

[Hu9o]

Nou je hebt niet genoeg info

Het gaat om een mediatheek systeem, er kunnen dus 3 mediasoorten worden uitgeleend. Item heeft info over de titel, het genre (lach film/ pc spel enzo).
In CD zit info over het aantal tracks en de artiest
DVD: film lengte, taal (dvd films)
CDrom: os en minimum systeem enzo.

[curry684]

De meeste mediatheken verhuren echter ook movieboxen, leen-DVD-spelers etc.

Ik vind 'Item' hoe dan ook geen goede naam voor je base class In 'RentItem' horen dingen thuis als de 'huidige huurder', 'huurverloopdatum', 'boete' en zo, daar inherit je een 'MediaRentItem' van die 'genre', 'publisher', 'year' en 'titel' introduceert, en daarna pas in CDRentItem etc. introduceer je de hele specifieke elementen.

[Hu9o]

Daar heb je wel gelijk in, maar het gaat hier om een opdracht om OO in C++ te leren. Deze opdracht is dus redelijk overzichtelijk en klein. Dus binnen dit programma is de naam Item voldoende omschrijvend.

Trouwens de huurder staat niet in Item of een subklasse daar van. Maar dat gaat met een associatie van een klasse onder Klant.

[whoami]

Waarom zou jij de huurder vastleggen in het RentItem?

Ik zou eerder een class 'Huurder' maken, en voor ieder 'verhuurbaar item' een concrete class die van een bepaalde base-class of interface (RentItem) overerft.

In 'Huurder' hou je dan de gegevens bij over de huurder (naam, adres, enzo), en hou je dmv een aggregatie bij welke RentItems die huurder gehuurd heeft.

Ik kan hier geen UML diagrammetje maken of uploaden, maar 'Verhuurder' zou dan dus een ArrayList oid moeten hebben van het type RentItem.

[Hu9o]

Ik geloof dat je m'n laatse zin niet goed gelezen hebt. Daar staat dat in een klas (History_record) onder Klant (aggregatie) wordt opgeslagen welke items die klant allemaal geleend heeft. Dit gebeurt via een assiociatie dmv een pointer.

Als ik kon inloggen op m'n Lycos account, dan zou ik het klassendiagram posten, maar om een of andere krijg ik steeds melding dat m'n pass fout is (wat niet het geval is). Maar dat terzijde.

Ik denk dat m'n vraag voldoende beantwoord is

[whoami]

Hu9o schreef op 09 februari 2004 @ 11:53:
Ik geloof dat je m'n laatse zin niet goed gelezen hebt. Daar staat dat in een klas (History_record) onder Klant (aggregatie) wordt opgeslagen welke items die klant allemaal geleend heeft. Dit gebeurt via een assiociatie dmv een pointer.

Ik reageerde op curry684 z'n reply. (Zie de tijd van mijn post, en de tijd van de jouwe.)

Jouw oplossing zal idd ongeveer hetgeen zijn wat ik bedoelde in mijn post, maar we hebben het alletwee tegelijk gepost.

[curry684]

Hu9o schreef op 09 februari 2004 @ 11:35:
Daar heb je wel gelijk in, maar het gaat hier om een opdracht om OO in C++ te leren. Deze opdracht is dus redelijk overzichtelijk en klein. Dus binnen dit programma is de naam Item voldoende omschrijvend.

Als je OO aan het leren bent moet je het juist goed doen en je er niet 'lui' vanaf maken met een niet kloppend model.

Trouwens de huurder staat niet in Item of een subklasse daar van. Maar dat gaat met een associatie van een klasse onder Klant.

Bliep, je hebt toch een 1..* relatie van Klant -> Items, waarom initieer je de 'connectie' dan vanuit klant? Je wil toch bij ieder item ook op kunnen zoeken welke klant 'm heeft op dat moment?

whoami schreef op 09 februari 2004 @ 11:35:
Waarom zou jij de huurder vastleggen in het RentItem?

Ik zei niet dat ie er met naam en toenaam in moest staan, ik vind een 'foreign key' naar de huurder ook voldoende

Overigens hebben we het hier over een classmodel en niet een databasemodel, anders zou je ook een aparte koppeltabel 'rentals' moeten hebben om alle historische verhuurinformatie van iedere klant te kunnen achterhalen e.d. In een simpel non-historic classmodel is een pointer vanuit rentable item naar huidige huurder afdoende imho (zeker voor een simpele opdracht).

[ Voor 16% gewijzigd door curry684 op 09-02-2004 12:02 ]

[whoami]

IMO ga je in een IRL situatie niet je volledige database in het geheugen gaan inladen.
Als je wilt weten wie een bepaalde video gehuurd heeft, zal je dat laten doen dmv een SQL query op je databank en kan je niet vertrouwen op de op dat moment ingeladen objecten.
Je kan ook niet blijven vertrouwen op de gegevens die je in het geheugen hebt zitten, want wie zegt dat die nog altijd de juiste situatie weergeven?

[Hu9o]

curry684 schreef op 09 februari 2004 @ 12:00:
[...]

Als je OO aan het leren bent moet je het juist goed doen en je er niet 'lui' vanaf maken met een niet kloppend model.

WAT?!! Hoe weet jij nou dat mijn klassendiagram niet klopt?? En hoe kom je er bij om te zeggen dat ik me er lui vanaf maak?

[...]

Bliep, je hebt toch een 1..* relatie van Klant -> Items, waarom initieer je de 'connectie' dan vanuit klant? Je wil toch bij ieder item ook op kunnen zoeken welke klant 'm heeft op dat moment?

Het is niet de bedoeling om op te vragen welke klanten de items op dit moment hebben. Wel de andere kant op, dus welke items heeft deze klant.

[curry684]

Hu9o schreef op 09 februari 2004 @ 12:19:
[...]

WAT?!! Hoe weet jij nou dat mijn klassendiagram niet klopt?? En hoe kom je er bij om te zeggen dat ik me er lui vanaf maak?

'Lui' stond tussen apostrofjes, dus chill Maar je zegt het wel letterlijk: "omdat dit maar voor een introductieopdracht is hoef ik geen dekkende namen te bedenken en op de toekomst voorbereide class-trees te bedenken."

Fact is: je klassendiagram klopt niet. Als je er niet naderhand andere verhuurbare items in kunt frotten klopt hij simpelweg niet. Als je de naam 'item' of 'object', per definitie een enorme baseclass, een goede plaats vind om verhuurspecifieke elementen te introduceren klopt je klassenmodel gewoon niet.

Daarnaast zeg je dat jij degene bent die OO in C++ aan het leren is. Ik vind het een beetje vreemd dat je dan direct zo geagiteerd van leer trekt als iemand die dat al een jaar of 8-9 doet je op een paar fouten wijst...

Het is niet de bedoeling om op te vragen welke klanten de items op dit moment hebben. Wel de andere kant op, dus welke items heeft deze klant.

Wat een wazige insteek... als een verhuurd item na 2 jaar nog niet ingeleverd is wil je toch weten welke klant dat op z'n geweten heeft?