Ach zo, nu denk ik dat ik het ongeveer snap. Bedankt, je voorbeeld heeft echt geholpen
Maar je hebt wel gelijk, het komt erop aan om het veel te oefenen en te gebruiken (wat ik nu dus ook ga doen )
Ach zo, nu denk ik dat ik het ongeveer snap. Bedankt, je voorbeeld heeft echt geholpen
Maar je hebt wel gelijk, het komt erop aan om het veel te oefenen en te gebruiken (wat ik nu dus ook ga doen )
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987
ultddave (15 January 2010)
Nog een voorbeeld waar het gebruikt kan worden. Ik heb het onlangs moeten gebruiken (Wel in C++):
Ik moest een schaakspel maken. Nu, hoe zou jij de klassen maken voor de schaakstukken? Op dit moment zou jij waarschijnlijk dit doen:
- Voor elk soort schaakstuk een klasse maken (voor een paard, pion, loper, koning, ...)
Ok, stel dat je dat zo doet. Nu moet je een klasse "spelbord" gaan maken. En in die klasse zit dus een 2 dimensionale array dat het spelbord/speelveld voorstelt.
Nu komt uiteraard het probleem. Welk type moet die array zijn? Je kan moeilijk een array van Koningen of pionen maken? Want je zit met meerdere schaakstukken... En de schaakstukken moeten kunnen bewegen op het veld, dus het type van elk veld ligt nooit vast.
Dju. Wat nu?
Hier komt dus polymorfisme en dus het gebruik van abstract klassen goed van pas. Je moet dus een extra klasse maken, genaamd "schaakstuk". In deze klasse komt alle gemeenschappelijke informatie dat dus alle soorten schaakstukken (paard, pion, ...) gemeen hebben.
Bijvoorbeeld de variabelen/attributen: Positie en kleur. (Om maar snel iets te zeggen)
Specifieke informatie van elk schaakstuk. Bijvoorbeeld, hoever een Pion mag bewegen en dergelijke, wordt opgeslagen in de klasse Pion zelf. Pion en de andere schaakstukken moeten dan "overerven" van de klasse "schaakstuk". Wat logisch is, want ze zijn allemaal schaakstukken.
Wat hebben we dan tot nu toe? We hebben een 1 base class (schaakstuk) en een aantal afgeleide klassen (paard, pion, toren, koning, koningin, loper).
Nu om het probleem met het veld op te lossen. Het veld moet dan van het type "schaakstuk" zijn. (Dus een array van 64 schaakstukken). En dan maak je bijvoorbeeld een koning aan door deze actie:
Dus nu heb je een koning. Dat dus een schaakstuk is. Die koning kan je nu op eender welk veld plaatsen. Zonder problemen te hebben met types.schaakstuk MijnSchaakstuk;
MijnSchaakstuk = new Koning();
Idem voor alle andere stukken uiteraard.
PS: Uiteraard gaat "schaakstuk" ook abstract functies hebben, die ook in Koning, Loper, ... bestaan. Waardoor dat "MijnSchaakstuk".beweeg() bijvoorbeeld de respectievelijke functie oproept voor de juiste klasse.
Als MijnSchaakstuk een Koning is, gaat hij "beweeg()" van Koning oproepen. Als hij een Pion is, zal hij die van Pion oproepen. Als de klasse geen "beweeg()" functie zou hebben, dan zal hij de functie in "schaakstuk" zelf oproepen (indien gedefinieerd). Tenzij die volledig abstract is, en dus geen body heeft.
Mvg,
Dave
Laatst gewijzigd door ultddave; 15 January 2010 om 22:22
"Friendship. It's the hardest thing in the world to explain. It's not something you learn in school. But if you haven't learned the meaning of friendship, you really haven't learned anything." ~ Muhammad Ali
Toelly (15 January 2010)
Bedankt Echt een supervoorbeeld. Ik ga er morgen zeker ook een paar proberen te maken. In ieder geval al bedankt Martijnc en ultddave voor jullie hulp. Ik zie nu alles al veel helderder. Indien ik nog vragen heb, zal ik ze hier zeker posten
PS @ ultddave: Zit jij toevallig op de univ gent in de eerste bachelor informatica? (Gezien je opdracht van een schaakspel )
0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987
ultddave (16 January 2010)
Dave, ik denk dat ge mij zojuist ietske meer OOP hebt doen verstaan.
Heeft iemand toevallig nog documentatie staan over OOP in het algemeen (dus niet toegepast op een bepaalde taal)?
Ook documentatie over design patterns is welkom
Dank
Zeg maar Pieter
Als je informatie wilt over design patterns kan ik je dit boek aanraden:
http://www.amazon.com/Design-Pattern.../dp/0201633612
2e bachelor ICT op de universiteit hasselt. Dat schaakspel was een klein project (duurde maar 2 weken en ging niet op punten) voor te leren werken met die abstracte klassen.
In het eerste jaar zien wij: Java, C, Perl, PHP, XHTML, CSS, JavaScript, MySQL, Ajax, Visual Basic (basis), Linux & Windows scripting (voor de terminal/commandline), ProLog (programming in Logic) das een 5GL taal, Assembler, XML, Glade & GTK (voor GUI's)
In het tweedde jaar zien we dan: Java (OO programming & multithreaded programming), C++ (OO programming & multithreaded programming), openGL, SQL en gaan we verder met Ajax, Java Server Pages en dergelijke
Nu heb ik een trimesteroverschrijdend project, over het bordspel "Kolonisten van Catan".
***
Een belangrijke tip voor OO programmeren lijkt me dat ge eerst goed moet kijken wat uw programma moet doen. En dat ge dan pas uw datastructuren en klassen gaat aanmaken. En dus niet direct vanop het zicht, direct klassen gaat aanmaken die ge denkt nodig te hebben.
Bijvoorbeeld, stel dat ge een 'kaartspel' moet maken. Is het nodig om een klasse 'kaart' te maken? Opzich kunt ge gewoon de kaarten nummeren van 1-13 (Aas = 1, 13 = Heer) afhankelijk van het speltype, kunt ge ook 2-14 als Aas het hoogste is. En dan gewoon met Integers werken en dan de nummers vergelijken.
int kaart1 = 5;
int kaart2 = 12;
if(kaart1 > kaart2)
printf("Kaart 1 is beter");
else if(kaart1 < kaart2)
printf("Kaart 2 is beter");
(Ge kunt dan ook enumeration gebruiken om alles duidelijker te maken. Of constanten. Dat ge zegt dat bijvoorbeeld de Dame = 12. En dat ge dan zegt:
int kaart 2 = DAME;
Das iets duidelijker dan "12". )
Dus opzich moet ge nooit te snel klassen gaan aanmaken die logisch lijken. Een kaartspel zonder klasse "kaart" lijkt niet logisch, maar het gaat makkelijk.
Uiteraard moet ge dat zien van situatie tot situatie. Want uiteindelijk, als ge met een GUI werkt. Moet ge misschien toch ergens een 'kaart' klasse gebruiken want elke kaart moet zijn texture nog hebben en misschien nog andere eigenschappen waar ik niet direct aan denk.
***
En vrij belangrijk, waar leerkrachten meestal op letten, is dat ge moet zorgen dat elke klasse doet wat hij moet doen. Niet meer, niet minder. Dus uw "schaakspel" (main klasse) moet dus niet vertellen tegen een Pion van "Gij zijt een Pion, dus kunt ge maar 1 vak vooruit gaan". Maar die moet wel zeggen van "Yo Pion, ga naar vak A7". En de "Pion" weet van zichzelf dat hij een Pion is, en dat hij maar 1 vak kan bewegen. Dus die Pion voert die actie dan uit, of returned dat da niet mogelijk is.
Want ik had eerst bijna alles in men "main klasse" gezet :P. Da was dus nogal verkeerd .
Maar ge ziet direct als het fout loopt, dan begint ge meestal functies te implementeren met een grote "select case" (switch) of lange If Else structuren.
Zo had ik eerst:
If(Stuk == "Koning")
// Doe X
else if(Stuk == "Koningin")
// Doe Y
else if(...)
...
Nu als ge da ziet staan, is da meestal ni echt goe :P. Dan kunt ge dus beter met zo een "schaakstuk" klasse werken zoals ik al zei.
Dan doet ge dus:
Stuk.Action();
En dan zorgt ge gewoon dat die functie "Action()" abstract is, en dan zal de juiste functie in ofwel Koning of Koningin of ... aangeroepen worden. En da is eigenlijk maar 1 regel ipv die hele If Else structuur :P.
***
Das zowat het belangrijkste dat ik tot nu toe heb ondervonden .
Greetz,
Dave
"Friendship. It's the hardest thing in the world to explain. It's not something you learn in school. But if you haven't learned the meaning of friendship, you really haven't learned anything." ~ Muhammad Ali
Jou richting ziet er echt hoogst interessant uit Dave :o !
https://twitter.com/Fck___
ultddave (16 January 2010)
De reden om die grote selectiestructuren aan te passen is uitbreidbaarheid en aanpasbaarheid he Stel dat er ooit een nieuw stuk komt dat 3 vakken links of rechts kan bewegen ? (niet waarschijnlijk, maar is een stom voorbeeld) Dan moet je gewoon de interface schaakstuk implementeren in een nieuwe klasse voor dat stuk, en misschien 1 of 2 regeltjes aanpassen elders.
Zoniet moet je een hele case structuur gaan toevoegen enz.
War je daar zegt over nadenken voor je programmeert (= ontwerpen) klopt helemaal Als je dat nog niet gezien hebt voel je dat wel mooi aan.
Ik zie jammer genoeg een pak minder talen :( In het eerste jaar was dat java, html, javascript, beetje SQL en dit semester kwam daar juist XML en xobol bij :(
Laatst gewijzigd door carl; 16 January 2010 om 09:50
ultddave (16 January 2010)
ultddave (16 January 2010)
Toegepaste informatica (profesionele bachelor @ hogent)
ultddave (16 January 2010)
Momenteel bekijken 1 gebruikers deze discussie. (0 leden en 1 gasten)
Favorieten/bladwijzers