[C++ / ALG] Problemen met het maken van classes

[Verwijderd]

Hallo!

Ik heb net een cursus C++ achter de rug, en ik wou nu wat gaan oefenen. Om het een beetje leuk te houden, heb ik wat bedacht ivm. mijn hobby: voetballen.

Wat ik wil maken: een programma dat per competitie (champ. league, ...) de teams bijhoudt die eraan meedoen, en per team de spelers (met hun profiel, prestaties, ..).

Het probleem is dat ik geen ervaring heb met het maken van grote programmas, en dat ik dus niet goed weet hoe ik er eigenlijk aan moet beginnen.
Na wat literatuur te lezen over programming-design, heb ik volgende 3 voorstellen kunnen "bedenken".

voorstel 1:
--> Een klasse League: naam, lijst teams, lijst players, array relatie teams<->players
--> Een klasse Team: naam, land, voorzitter, ...
--> Een klasse Player: naam, land, goals, ...

In de klasse League hou ik een lijst (bijv. een array) van objecten van het type Team + een lijst van objecten van het type Player. Eenmaal ik deze 2 lijsten gemaakt heb, maak ik een array aan met lengte het aantal teams, en met indices telkens een lijst van spelers. De bedoeling van deze array is dat ik de relatie kan leggen dus een team (een index (komt overeen met een teamid) in de array), en de spelers van dat bepaald team (de lijst die aan die index hangt.)

voorstel 2:
--> Een klasse League: naam, wat pure virtual functies zoals "geefInformatie()"
--> Een klasse Team : public League: naam, land, voorzitter, geefInformatie(), ...
--> Een klasse Player : public Team: naam, land, goals, geefInformatie(), ...

Hier ga ik Team afleiden van League, en Player op zijn beurt van Team. Ik krijg dus een soort boomstructuur League->Team->Player. In deze opzet kan ik gebruik maken van de voordelen van inheritance: ik kan functies herdefiniëren met dezelfde betekenis, ik kan gebruik gaan maken van polymorfisme, ...

voorstel 3:
--> Een klasse Player: naam, land, goals, ...
--> Een klasse Team : public Player: naam, land, voorzitter, ...
--> Een klasse League : public Team: naam, ...

Hier ga ik voorstel 2 op zijn kop zetten: Player->Team->League

Mijn probleem is nu dat ik niet weet welk voorstel ik moet kiezen, omdat ik niet goed weet in welke gevallen ik bijvoorbeeld inheritance moet gaan gebruiken, en in welke gevallen juist niet. Een probleem in voorstel 2 en voorstel 3 is volgens mij dat ik telkens dubbele informatie moet gaan ingeven: telkens als ik een nieuwe speler aanmaak, moet ik per speler altijd opnieuw heel de ploeg-informatie + league-informatie gaan ingeven, omdat ik anders onvolledige structuren krijg. Dit probleem heb ik met voorstel 1 niet. Langs de andere kant kan ik in voorstel 1 niet echt gebruik maken van de voordelen van OO in C++, omdat in dat geval geen sprake is van inheritance/polymorfisme/function overloading/...

Hoe zouden jullie dit aanpakken? Is 1 van mijn voorstellen oké, of moet ik een tussenweg proberen te zoeken tussen de verschillende voorstellen?

Liefst ook goed funderen, want zoals je ziet ben ik niet echt mee in het opstellen van een structuur

_{ps: dit was mijn eerste post! aangenaam!}

[.oisyn]

voorstel 2 en 3 kloppen van geen kant (opbouwende kritiek, geen afzeikmening )

in voorstel 2 zeg je namelijk dat een team een uitbreiding is op een league. Dat is natuurlijk niet zo. Ook heeft een league meerdere teams, dat kun je op die manier dan al niet meer bereiken

voorstel 3 net zo, maar dan andersom: een team is geen uitbreiding van player, maar een verzameling van players... een 1 op veel relatie dus, maar geen sub/superklasse

Overigens zeg je dat je voorstel 1 minder goed vind omdat daar geen inheritance enzo in voorkomen. Maar dat is helemaal niet verplicht. Inheritance is noodzakelijk als je 2 typen klassen hebt, waarbij de ene klasse een uitbreiding is van de andere.
Een Auto is bijvoorbeeld een uitbreiding op VervoerMiddel (om maar even een voorbeeld te noemen)

Nog even een toevoeging: in voorstel 1 heeft een League een lijst met spelers, en daar sla je de relatie speler <-> team ook in op. Maar het is voor een League helemaal niet van belang op de spelers te weten (imho), en het is al helemaal niet zijn taak om de relaties bij te houden. Het enige wat ie hoeft te weten is een lijst met teams. Elk team moet welk weer bijhouden welke spelers er in dat team zitten

[Verwijderd]

Heb het heel snel ff uitgewerkt, in het geval het niet echt duidelijk zou zijn

code:

/*voorstel 1*/
class League
{
        lijst van landen
        lijst van spelers
        array (lengte aantal landen) van lijst met spelers

        naam, afkorting, ...
}

class Team
{
    naam, voorzitter, stadium, ...
}

class Player
{
    naam, voornaam, aantal goals, ...
}

/*voorstel 2*/
class League
{
    naam, afkorting, ...

}

class Team : public League
{
    naam, voorzitter, stadium, ...
}

class Player : public Team
{
    naam, voornaam, aantal goals, ...
}

/*voorstel 3*/
class Player
{
    naam, voornaam, aantal goals, ...
}

class Team : public Player
{
    naam, voorzitter, stadium, ...
}

class League : public Team
{
    naam, afkorting, ...
}

[Verwijderd]

.oisyn schreef op 29 oktober 2002 @ 21:41:
voorstel 2 en 3 kloppen van geen kant (opbouwende kritiek, geen afzeikmening )

in voorstel 2 zeg je namelijk dat een team een uitbreiding is op een league. Dat is natuurlijk niet zo. Ook heeft een league meerdere teams, dat kun je op die manier dan al niet meer bereiken

voorstel 3 net zo, maar dan andersom: een team is geen uitbreiding van player, maar een verzameling van players... een 1 op veel relatie dus, maar geen sub/superklasse

Cool! Heb iets fundamenteel bijgeleerd denk ik Je kan alleen gaan afleiden, als je een duidelijke specificatie/uitdieping van je object hebt? Ik kan dus Team niet gaan afleiden van League, omdat Team geen specificatie is van League, maar een gewone onderverdeling? (en ik dus een verzameling ga maken, zoals jij zegt). Hetzelfde voor Player van Team.

Overigens zeg je dat je voorstel 1 minder goed vind omdat daar geen inheritance enzo in voorkomen. Maar dat is helemaal niet verplicht. Inheritance is noodzakelijk als je 2 typen klassen hebt, waarbij de ene klasse een uitbreiding is van de andere.
Een Auto is bijvoorbeeld een uitbreiding op VervoerMiddel (om maar even een voorbeeld te noemen)

Dat snap ik, inheritance is geen doel op zich, maar ik dacht dat het op zo'n geval toepasbaar zou zijn!

Als jij dit zou moeten realiseren, hoe zou jij de structuur dan opbouwen? Zou jij ook voorstel 1 volgen, of bestaan er nog andere (betere?) technieken?

[ Voor 0% gewijzigd door Verwijderd op 29-10-2002 21:52 . Reden: wat betekent dit? ]

[whoami]

Voorstel 2 klopt idd niet.
De manier waarop je wilt afleiden is verkeerd. Als League pure virtual functions bevat, kun je afaik geen objecten van die class instancieren.
En inheritance heeft als bedoeling het minder abstract maken van een class, maw, meer gespecialiseerde functionaliteit toevoegen aan een class. Jij wilt dmv inheritance een onderlinge relatie tussen de classes definieren.

[.oisyn]

Verwijderd schreef op 29 oktober 2002 @ 21:49:
[...]
Cool! Heb iets fundamenteel bijgeleerd denk ik Je kan alleen gaan afleiden, als je een duidelijke specificatie/uitdieping van je object hebt? Ik kan dus Team niet gaan afleiden van League, omdat Team geen specificatie is van League, maar een gewone onderverdeling?

Juist! Maar misschien is het handig om eerst een cursus OOP te doen? (of een boek erover kopen oid ) OO denken is namelijk niet iets wat je zomaar leert

Dat snap ik, inh. is geen doel op zich.

Als jij dit zou moeten realiseren, hoe zou jij de structuur dan opbouwen? Zou jij ook voorstel 1 volgen, of bestaan er nog andere (betere?) technieken?

Ja idd, maar daar had ik nog een opmerking over in mijn vorige post, maar dat had ik pas later toegevoegd dus je hebt het misschien gemist:

Nog even een toevoeging: in voorstel 1 heeft een League een lijst met spelers, en daar sla je de relatie speler <-> team ook in op. Maar het is voor een League helemaal niet van belang op de spelers te weten (imho), en het is al helemaal niet zijn taak om de relaties bij te houden. Het enige wat ie hoeft te weten is een lijst met teams. Elk team moet welk weer bijhouden welke spelers er in dat team zitten

[Verwijderd]

je benadering is nogal vreemd imho...

Een team is een verzameling van spelers met nog een aantal attributen.
Een league is een verzameling van teams met nog een aantal attributen.

Een logischere opbouw zou dan zijn :

C++:

class Player
{
  naam, adres, salaris, etc.
};

class Team
{
  lijst van spelers (std::vector<Player>)
  voorzitter, vestigingsplaats, etc.
};

class League
{
  lijst van teams (std::vector<Team>)
  leaguebaas, oprichtingsdatum, etc.
};

[Verwijderd]

Cool! thanks guys, hier kan ik met verder werken om mijn basis te leggen! Waarschijnlijk zal ik nog problemen tegenkomen, maar die horen jullie dan wel.

En inderdaad: Ik heb mijn cursus c++ te "technisch" gehad. De echte principes/beginselen van OO'ing heb ik niet echt in detail gezien. Een boek is onderweg (de naam schiet me even niet te binnen).

Suggesties blijven uiteraard welkom! Ik ga beginnen met het maken van deze 3 classes (zoals jullie ze aangaven, en Akhorahil ze even uittypte).

[curry684]

Inheritance moet je zo zien:

C++:

class Persoon
class Hooligan : public Persoon
class Coach : public Persoon
class Speler : public Persoon
class Aanvoerder : public Speler

En even pesten:

C++:

class SpelendCoach : public Aanvoerder, public Coach

[Verwijderd]

/me snapt het!

Persoon
Hooligan is een soort persoon
Coach is een soort persoon
Speler is een soort persoon
Aanvoerder is een soort Speler
SpelerCoach is tegelijk een Aanvoerder en Coach (multiple inheritance)

Vraagje: bij SpelerCoach krijg je zeker virtual functies, omdat je anders zeg maar "dubbel" keer je persoon-members hebt/kan aanroepen?

[.oisyn]

Nee, je krijgt virtual base classes, omdat je anders last krijgt van ambiguiteit (zowel Aanvoerder als Coach overerven Persoon's members... zonder virtual base bestaat SpelerCoach dus in feite uit 2 Personen)

virtual functions zijn weer bedoeld voor overerving. Als ze niet virtual zijn en je roept ze op een baseclass aan, dan wordt de implementatie van een derived class niet aangeroepen. Als ze wel virtual zijn wel

[curry684]

Om virtual te demonstreren:

C++:

#include <stdio.h>

class Base
{
public:
  void NonVirtual()      { printf("Base::NonVirtual"); }
  virtual void Virtual() { printf("Base::Virtual"); }
};

class Derived : public Base
{
public:
  void NonVirtual()      { printf("Derived::NonVirtual"); }
  virtual void Virtual() { printf("Derived::Virtual"); }
};

int main()
{
Base*      l_Base = new Derived;

l_Base->Virtual();
l_Base->NonVirtual();
delete l_Base;
}

Over het algemeen doet dit stukje code compileren en analyseren het beter dan 20 pagina's zweverige uitleg

[curry684]

Om virtual base classes te demonsteren heb je echt plaatjes nodig, dus daarvoor verwijs ik je even door naar de uitleg van oom Microsoft.

Hier vind je tevens goede en vooral bondige uitleg over multiple inheritance en aanverwante problemen (destructorvolgorde en zo)

[.oisyn]

[nohtml]

curry684 schreef op 30 oktober 2002 @ 21:59:
Om virtual base classes te demonsteren heb je echt plaatjes nodig, dus daarvoor verwijs ik je even door naar de uitleg van oom Microsoft.

oh daar had ik zo'n goede uitleg over weetjenog, even opzoeken
ah hier: curry684 in "Voordeel van classes?"