[alg] oo theorie

[trekker22]

genoeg dingen met geprogrammeerd in bv delphi en Java, maar niet echt OO georienteerd. (vaak omdat het ook maar kleine dingen waren)

probleem:
- ik ben op zoek naar informatie die mij meer in de OO trant leert denken. Op dit moment programmeer ik bijna alleen maar procedureel, en nog nooit geleerd om een compleet systeem in objecten uit te denken.

een voorbeeld:

ik wil een kaartspelletje maken als "Toepen"
- met computer spelers, en menselijke spelers.

Hoe denk ik dit uit in objecten? Welke objecten zou je gebruiken?

Als ik zo iets probeer te analyseren, dan denk ik meteen weer procedureel:

- spel start
- kaarten schudden
- spelers aanmaken
- deler bepalen
- kaarten delen
- for i:= 0 to aantal rondes (4, want 4 kaarten)
"winnaar/beginner" gooit kaart op
de andere spelers gooien hun kaart op
bepalen wie de "winnaar/beginner" voor de volgende kaart is
next

maar dit is duz niet echt OO.

Gevraagd:
- informatie over hoe ik zelf meer in OO leer denken, toegepast in meerdere situaties
- welke objecten/classess zouden jullie voor dit soort spelletje aanmaken?

[Cyphax]

Het beste dat je misschien kunt doen is info zoeken over de basics van OO programmeren.
Met google kom je dan op zoiets uit.
Er zijn ongetwijfeld veel sites die je kunnen vertellen over de basics van OO programmeren.

As for toupen: ik zou de klassen 'spel', 'ronde', 'speler' en 'kaart' aanmaken om mee te beginnen. Waarschijnlijk kom je als je bezig bent nieuwe dingen tegen waarvan je een klasse wilt maken. Je moet er even inkomen maar dan is OO programmeren toch wel mooi

[Janoz]

Bij oo moet je niet in tijd, maar in objecten en interacties tussen die objecten denken. In je voorbeeld zal je bijvoorbeeld een speler object hebben. Daarnaast heb je een 'game master' object dat het spel zelf voorsteld. Bij oo is het van belang dat je kleine brokjes functionaliteit maakt die samen grote dingen doen. Voor je spel object maakt het namelijk helemaal niet uit of het speler object een gebruiker met zijn toetsenbord is of een supercomputer die alle mogenlijke setten kan doorberekenen. Het enige dat het spel object zou doen is aangeven dat iemand zijn kaart op mag gooien en welke kaarten hij heeft.

Wat trouwens heel erg belangrijk is, is dat je de weergave loshaalt van de logic. Het spel object hoeft bijvoorbeeld helemaal niet te weten of de opgegooide kaarten nu via een state of the art 3d engine worden gerenderd, of gewoon in een tekst console. Ook hier is heeft uit elkaar trekken van de onderdelen voordelen.

[Yoeri]

Bekijk het eens als volgt:

Ik wens een spel te maken net als Toepen. In Toepen heb je twee spelers met elk een naam, die elk vier kaarten krijgen. Een speler kan een kaart leggen of passen


Duid je relevante zelfstandige naamwoorden aan, dit worden klassen en hun eigenschappen of properties (speler -> naam)
Duid de relevante werkwoorden aan, dit worden methodes van klassen

[Jelmer]

Ikzelf zou, als het je om het OO denken gaat, een wat concreter voorbeeld gebruiken. Bijvoorbeeld de mens. Een Mens heeft ouders en misschien ooit kinderen (welke allen uiteraard ook van het type 'Mens' zijn). Tevens is een Mens op een bepaald tijdstip geboren. Het supertype van Mens is Zoogdier. Onder Zoogdier vallen weer allerlei dieren.

Een Mens woont in een Huis. Huis heeft een Adres. 'Mens' kun je een methode geven 'verhuisNaar(Huis nieuwHuis)', enz.

[ Voor 10% gewijzigd door Jelmer op 12-04-2004 20:17 ]

[trekker22]

Bij oo moet je niet in tijd, maar in objecten en interacties tussen die objecten denken.

En dat is juist precies wat ik altijd al doe: denken in tijd, want dit vind ik het meest makkelijk om na te gaan hoe het in de werkelijkheid gaat. Want het spelletje wordt altijd in een zelfde volgorde gespeelt --> procedureel.

En om een OO manier te gaan denken, dat lukt duz niet echt.

Ik zal eens wat met dat werkwoorden/zelfstandige naamworden idee gaan spelen

[Macros]

Procedureel is niet heel anders dan OO. OO is een vorm van procedureel werken. Alleen nu dat in plaats van je programma bestaat uit een hoop functies met global data en data dat heen en weer gepaast wordt tussen de functies bestaan die functies nu in objecten en bevatten die objecten de data die bij hun hoort.
Die volgorde van tijd bestaat nog steeds in OO proggen, alleen denk je nu niet na tussen de interactie van de procedures maar tussen de objecten enhun methodes.

[whoami]

Robbedoeske schreef op 12 april 2004 @ 20:15:
Bekijk het eens als volgt:

Ik wens een spel te maken net als Toepen. In Toepen heb je twee spelers met elk een naam, die elk vier kaarten krijgen. Een speler kan een kaart leggen of passen


Duid je relevante zelfstandige naamwoorden aan, dit worden klassen en hun eigenschappen of properties (speler -> naam)
Duid de relevante werkwoorden aan, dit worden methodes van klassen

Je kan idd op die manier beginnen om classes te identificeren. Echter, eens je meer ingewikkelde systemen gaat bouwen, zal je ook in termen van abstraction moeten gaan denken; kijken welke classes een gemeenschappelijke interface kunnen hebben etc.... (commonality/variability analyse bv. zie ook het werk van Coplien).

[Yoeri]

whoami schreef op 12 april 2004 @ 20:57:
[...]


Je kan idd op die manier beginnen om classes te identificeren. Echter, eens je meer ingewikkelde systemen gaat bouwen, zal je ook in termen van abstraction moeten gaan denken; kijken welke classes een gemeenschappelijke interface kunnen hebben etc.... (commonality/variability analyse bv. zie ook het werk van Coplien).

mja... tuurlijk... maar ik vind deze methode wel handig om te illustreren hoe je begint te denken bij oo programmeren... de rest volgt natuurlijk wel maar je moet eenvoudig beginnen

[trekker22]

hoho, daar ben ik nog lang niet aan toe:)

zelfs bij zoiets simpels als dit kaartspelletje kan ik niet tot een klasse-model komen.

Ik heb best wel wat gelezen over OO tijdens mijn informatica opleiding, maar als ik zelf een concreet probleem wil oplossen dan kom ik er niet uit.

Zijn er nergens cases te vinden van concrete problemen (bv een kaartspelletje) die uitgewerkt wordt tot een klasse model?

[whoami]

Misschien vind je hier wel iets tussen.

Je kan doen zoals Robbedoeske al zei:
Schrijf eens alles in tekstvorm op, en identificeer de zelfstandige naamwoorden. Daar kan je classes van maken. De werkwoorden, daar kan je dan member-methods van die classes van maken, etc....

[Verwijderd]

ik denk dat 2 boeken echt behoorlijk op weg zouden helpen, vooral met alles erop heen.

Object-Oriented Software Engineering, Bruegge, Bernd en Dutoit, Allen H.
Agile Software Development, Martin, Robert C.

[AaroN]

Hier staat ook wel wat leuks:
Java Sun site

Verder heb ik het min of meer geleerd door middel van boeken. Heb talloze boeken gelezen over Object Oriented Problem Solving en Datastructuren. Verder kun je bijvoorbeeld het boek van Stroustrup kopen [C++ prog. Language], dat handelt over c++ met classes en dergelijke.

[Alarmnummer]

Verwijderd schreef op 12 april 2004 @ 21:32:
ik denk dat 2 boeken echt behoorlijk op weg zouden helpen, vooral met alles erop heen.
Agile Software Development, Martin, Robert C.

Hmm.. ik betwijfel hoeveel de topicstarter heeft aan dit boek. Dit boek gaat meer over de methodologie smaak: Agile Software Movement en dat is alleen handig als je al beter thuis bent in oo/software ontwikkeling.

[ Voor 5% gewijzigd door Alarmnummer op 12-04-2004 21:47 ]

[Verwijderd]

Alarmnummer schreef op 12 april 2004 @ 21:45:
[...]

Hmm.. ik betwijfel hoeveel de topicstarter heeft aan dit boek. Dit boek gaat meer over de methodologie smaak: Agile Software Movement en dat is alleen handig als je al beter thuis bent in oo/software ontwikkeling.

mua, dat valt best mee, het eerste boek neemt je mee door veel methodieken om tot een OO model te komen, vanuit dat OO model programmeer je : ) en ASD neemt je dieper mee in deze materie.

Je leert ermee denken, hoe zoek ik objecten? wat zijn objecten? welke objecten zijn van belang voor de klant? en hoe kom je verder?

Het programmeren in OO is vooral handig als je weet vanuit welke modelen in bijvoorbeeld UML je het kunt programmeren, en hoe je tot die modelen komt...

naja das mij mening : )

EDIT: Misschien kan TS toch eerst op internet zoeken : ) staat ook zoveel over OO... deze site is wel een leuke http://www.cetus-links.org/

[ Voor 8% gewijzigd door Verwijderd op 12-04-2004 22:04 ]

[Alarmnummer]

Verwijderd schreef op 12 april 2004 @ 21:56:
[...]
mua, dat valt best mee, het eerste boek neemt je mee door veel methodieken om tot een OO model te komen, vanuit dat OO model programmeer je : )

Je hebt me niets horen zeggen over dat 1e boek.

en ASD neemt je dieper mee in deze materie.

Volgens mij bedoel jij
Agile Software Development, Principles, Patterns, and Practices

En ik dacht deze:
Agile Software Development van Alistair Cockburn

De laatste gaat voornamelijk over de Agile Software Movement en daarbij gaat het meer om het ontwikkel traject en is alleen praktischer als je al iets verder bent gevordert. Het andere boek heb ik niet gelezen maar ik zie bij Amazon dat het een praktisch boek kan zijn voor de topic starter.

[ Voor 8% gewijzigd door Alarmnummer op 12-04-2004 22:15 ]

[Verwijderd]

Verwijderd schreef op 12 april 2004 @ 21:32:
ik denk dat 2 boeken echt behoorlijk op weg zouden helpen, vooral met alles erop heen.

Object-Oriented Software Engineering, Bruegge, Bernd en Dutoit, Allen H.
Agile Software Development, Martin, Robert C.

Nog eentje erbij

An Introduction to programming and object oriented design using java, Nino & Hosch

Ik heb dit boek hier liggen en ben eventueel wel bereid deze te verkopen, aangezien ik er toch niets meer mee doe

[trekker22]

eindelijk tijd gevonden omzelf mij model uit te werken, hiervoor gebruik ModelMaker.

diagram:


wat vragen/problemen:
- wat vinden jullie van deze objecten?
- relaties, kan iemand me uitleggen of ik in een dergelijk model relaties moet aanleggen? BV TSpel heeft als property een TKaartCollection, moet er dan een relatie worden aangemaakt tussen TSpel en TKaartCollection?

[Alarmnummer]

trekker22 schreef op 23 april 2004 @ 08:54:
eindelijk tijd gevonden omzelf mij model uit te werken, hiervoor gebruik ModelMaker.
wat vragen/problemen:
- wat vinden jullie van deze objecten?

Het zijn objecten die duidelijke concepten uit het domein aangeven.

- relaties, kan iemand me uitleggen of ik in een dergelijk model relaties moet aanleggen? BV TSpel heeft als property een TKaartCollection, moet er dan een relatie worden aangemaakt tussen TSpel en TKaartCollection?

Het lijkt me wel handig dat er relaties aangelegd moeten worden. Anders kan je nooit achterhalen waar een object bij hoort.

Je moet verder oppassen met binaire relaties (a verwijst naar b en ook andersom) omdat die veel problemen met zichmee brengen. Ik ben ze zelf niet vaak nodig.

[ Voor 8% gewijzigd door Alarmnummer op 23-04-2004 08:59 ]

[whoami]

Eigenlijk liggen die relaties er toch al als ik het zo bekijk?
TSpel bevat een member van het type TKaartCollection en TSpelerCollection.

Het is alleen niet zo gemodelleerd.

[trekker22]

waar wat is dan de bedoeling bij UML?

Moet ik deze dingen middels een Property aangeven?

Of moet ik dit aangeven door een relatie?

Mijn UML kennis is wat beperkt:s

[WildernessChild]

Handige link: UML in het kort.

Wat jij maakt heet in UML een Class Diagram. In het kort:
- 'Holle' pijltjes van subclasses naar superclasses. Die gebruik je hier niet, en lijkt me ook niet nodig. Tenzij je bijvoorbeeld een TMenselijkeSpeler en een TComputerSpeler gaat maken; die worden dan subclasses van TSpeler.
- Gewone pijltjes waar een object naar een ander verwijst. Bij de uiteinden zet je de 'multipliciteit' (meestal 1 of *). Bij één TSpelerCollection heb je bijvoorbeeld meerdere TSpeler-objecten, dus plaats je een 1 bij TSpelerCollection en een * bij TSpeler.
- Bij een relatie die wederzijds is (bijv. een TSpeler weet ook tot welke TSpelerCollection hij behoort) laat je het pijltje weg en teken je gewoon een lijntje.

Verder geef je de Create en Destroy operaties doorgaans niet aan, omdat je nu nog in de analyse-/ontwerpfase verkeert. Daarin is het nog niet van belang in welke taal je het gaat implementeren.

Verder heb ik voor mijn informaticastudie (RuG) het boek "Applying UML and Patterns" gebruikt van Craig Larman. Zelf vond ik het wat saai omdat ik het OO-denken wel al zo'n beetje onder de knie had, maar voor een beginner is het denk ik een geschikt boek. Het neemt je waarschijnlijk een hoop verder dan je op dit moment wilt gaan, maar het begint wel vanaf 0.

[ Voor 3% gewijzigd door WildernessChild op 23-04-2004 17:12 ]

[trekker22]

- die superklasse voor menselijke/computer speler wilde ik nog wel maken en zal ik dus gebruiken, komt later

- volgens die link is een pijltje een "association", en wordt gebruikt indien: "There is an association between two classes if an instance of one class must know about the other in order to perform its work", dus als ze iets van elkaar moeten weten.
In het geval van de TKaart -- TKaartCollection en TSpeler - TSpelerCollection is dit dus duidelijk het geval.
Maar bij andere gevallen weet ik het dus niet, bv.:

Moet er een relatie lopen van TSpel naar TSpelerCollection? Ik zou zeggen van niet, TSpel heeft immers een TSpelerCollection als property en weet dus als iets van TSpelerCollection af.

De vraag is dus:
- Als een klasse een andere klasse als property heeft, moet er dan wel/geen relatie tussen deze 2 klasses worden gelegd?

Zo tijd om te eten

[Alarmnummer]

[quote]trekker22 schreef op 23 april 2004 @ 18:51:
Moet er een relatie lopen van TSpel naar TSpelerCollection? Ik zou zeggen van niet, TSpel heeft immers een TSpelerCollection als property en weet dus als iets van TSpelerCollection af.
[/quote[
Dat is hetzelfde Er is dus geen verschil

[trekker22]

nou ik zie wel een verschil:

- bij de TKaart - TKaartCollection is er een relatie tussen deze 2, omdat de Collection moet weten hoe een TKaart "werkt", maar TKaartCollection heeft dus geen rechtstreekse property van het type TKaart, hij zal ergens intern een lijstje van gecreerde kaarten bijhouden.

Maar TSpel heeft andere klasse dus echt als property, indien het geval is, moet ik dan een relatie trekken tussen deze klasses?

Volgens mij zit ik een beetje moeilijk te doen, maar ik wil toch wel weten hoe het zit

[Alarmnummer]

trekker22 schreef op 23 april 2004 @ 19:15:
nou ik zie wel een verschil:

- bij de TKaart - TKaartCollection is er een relatie tussen deze 2, omdat de Collection moet weten hoe een TKaart "werkt"

Dat zou ik niet doen. Ik zou persoonlijk geenTKaartCollection class maken maar hier gewoon fijn een array voor gebruiken of een TCollection. Als jij een lijst hebt met kaarten erin, kan jij die lijst toch bijlangslopen om bv alle karten te delen:

code:

for(int k=0;k<kaarten.size;k++){
     Kaart kaart = (Kaart)kaarten[k];
     kaart.deel()
}

[trekker22]

ik zat ook te denken aan een TCollection.

Je bedoelt dat je TKaartenCollection erft van TCollection en daarna nog eigen methodes aan toekent (bv. schudden). Dat is wat ik zelf al in gedachten had.

Door er een klasse van te maken kan ik en het spel en de spelers een eigen groepje kaarten geven.

ruwweg het idee in mijn hoofd:

code:

//In Spel.Begin

ToepKaarten.Create(TOEP_KAARTEN)  // zorg dat er een reeks toepkaarten wordt aangemaakt

//In Spel.Deel

// geef een speler een kaart om mee te spelen, dit wordt herhaald tot elke speler 4 kaarten heeft.
Spel.ToepSpelers("mijn speler").KaartenInHand.Add = Spel.ToepKaarten.Remove

//In Speler.DoeZet
Result =  KaartenInHand.Remove(GEWENSTE_KAART)

// deze kaart zal dan op een of andere manier weer aan TSpel worden toegekend, bv. nog een TKaartCollection, die de gespeelde kaarten representeert.

Het idee is dus om de aangemaakte kaarten steeds door te spelen tussen de verschillende TKaartCollections. (ToepKaarten, KaartenInHand en GespeeldeKaarten)

wat vinden jullie van dit idee?

[trekker22]

trekker22 schreef op 23 april 2004 @ 19:51:
ik zat ook te denken aan een TCollection.

Je bedoelt dat je TKaartenCollection erft van TCollection en daarna nog eigen methodes aan toekent (bv. schudden). Dat is wat ik zelf al in gedachten had.

Door er een klasse van te maken kan ik en het spel en de spelers een eigen groepje kaarten geven.

ruwweg het idee in mijn hoofd:

code:

//In Spel.Begin

ToepKaarten.Create(TOEP_KAARTEN)  // zorg dat er een reeks 
//toepkaarten wordt aangemaakt

//In Spel.Deel

// geef een speler een kaart om mee te spelen, dit wordt herhaald tot 
//elke speler 4 kaarten heeft.
Spel.ToepSpelers("mijn speler").KaartenInHand.Add = Spel.ToepKaarten.Remove

//In Speler.DoeZet
Result =  KaartenInHand.Remove(GEWENSTE_KAART) 

// result : deze kaart zal dan op een of andere manier weer aan 
//TSpel worden toegekend,
//bv. nog een TKaartCollection, die de gespeelde kaarten representeert.

Het idee is dus om de aangemaakte kaarten steeds door te spelen tussen de verschillende TKaartCollections. (ToepKaarten, KaartenInHand en GespeeldeKaarten)

wat vinden jullie van dit idee? Lijkt misschien een beetje omslachtig allemaal

EDIT OEPS, op quote message gedrukt ipv EDIT
Sorry

[ Voor 6% gewijzigd door trekker22 op 23-04-2004 19:56 ]

[Alarmnummer]

trekker22 schreef op 23 april 2004 @ 19:51:
ik zat ook te denken aan een TCollection.

Je bedoelt dat je TKaartenCollection erft van TCollection en daarna nog eigen methodes aan toekent (bv. schudden). Dat is wat ik zelf al in gedachten had.

Dat deed ik vroeger maar dan krijg je zoveel nutteloze klasses. Ik zou (als je niet te veel complexiteit hebt) die functionaliteit gewoon onderbrengen bij speler of welk object verantwoordelijk ervoor is.

De manier van aanpak is behoorlijk afhankelijk van de functionaliteit/complexiteit. Ik kan 1001 oplossingen bedenken hiervoor maar ik denk dat het voor jouw situatie een beetje overkill is. Je zou met strategies kunnen worden om andere soorten speelgedrag eenvoudig kunnen toevoegen. Je zou het speelgedrag verder volledig onder kunnen brengen in een apart systeem als dit vraagt om zijn eigen conceptuele objecten.

Verder is het motto voor iedere programmeer ook nog steeds KISS (Keep It Simple Stupid). Vaak kan je een ontwerp vaak (imho) het beste laten groeien. Je ontdekt altijd nieuwe zaken en dat kan je dan kun je meteen uiten in het ontwerp. En als het je niet aanstaat, ga je refactoren totdat het ontwerp er wel uit ziet zoals je in gedachten hebt.

[ Voor 25% gewijzigd door Alarmnummer op 23-04-2004 21:33 ]

[Verwijderd]

tja leen of koop het boek van craig larman -> applying uml & patterns. daar lees je bijna alles over oo.