[Java] Hoe maak ik een optimaal OOP ontwerp?

[Verwijderd]

Hoe denken jullie op een OOP manier?

Dat is kort gezegd mijn probleem.

Ik ben bezig met een applet te maken: een spelletje vier op een rij met als mogelijkheden tegen de computer of met 2 spelers te spelen.

Het probleem dat ik ondervind, is dat ik er niet in slaag om de juiste indeling van classes en bijhorende methodes te kiezen.
Voor bijv. deze opgave kies ik momenteel volgende classes:
- een classe Spelbord die het bord op het scherm tekent
- een classe Munt die de kleur en positie van een munt bijhoudt
- de hoofdclasse met de initialisatie (init() methode ).


Nu ben ik echter al uren bezig aan het sukkelen om een correcte implementatie te zoeken voor bv. de a.i van de computer, op welke manier kies ik tussen het aantal spelers, ...

Een paar vragen die ik me stel:
Moet ik bv. de code van de ai in een aparte classe schrijven? Maar hoe laat ik deze samenwerken met de rest?
Is het niet zinloos om de classe Munt te ontwerpen?

Het lukt me niet om een juist ontwerp te maken voor zulke opgaves.

Mijn vraag is dan ook:
Hoe kiezen jullie welke classes met bijhorende methodes je ontwerpt? Welke benadering kies je hiervoor?

Hoe vertaal je een probleem naar klasses en methodes?

In mijn boeken "Thinking in Java" & "Java 2:Het complete handboek" heb ik de eerste hoofdstukken al een paar keren herlezen. Ik begrijp perfect wat classes zijn, hoe je objecten kunt zien als objecten om je heen. Hoe alles objecten kunnen zijn en berichten onderling kunnen uitwisselen.
Op verschillende sites tutorials gelezen die dit ook uitleggen, maar voorlopig nergens een uitleg gevonden met welke methode je een probleem kunt opslitsen in classes en methodes.

Ik kan ook een een Connect4 progje van het internet c/p; maar daarmee los ik mijn probleem niet op.

Topics die mijn probleem benaderden maar geen oplossing gaven:
Raakvlak tussen OOP en menselijke perceptie en cognitie
nut van zelf klasse maken in java

[ Voor 4% gewijzigd door Verwijderd op 08-02-2005 20:50 ]

[Verwijderd]

toevallig net het A* algoritme gehad met AI
http://www.policyalmanac.org/games/aStarTutorial.htm

[.oisyn]

Ten eerste, het is class of klasse, niet classe

een classe Munt die de kleur en positie van een munt bijhoudt

Waarom? Heeft het nut om van een munt een positie op te vragen? Of heeft het meer nut om te kijken welke munt, if any, zich op een gegeven positie bevindt?

Verder heb je natuurlijk een speelbord, twee spelers die om de beurt een zet doen, en een spel dat gespeeld wordt. Laatstgenoemde kan ervoor zorgdragen dat spelregels nageleefd worden, dat de juiste speler aan de beurt is en dat de winnaar bepaald wordt.

Ook moet je bedenken dat, of een speler nou een AI of een gebruiker achter de computer is, het in beide gevallen gewoon spelers zijn die een zet kunnen doen.

[Denker]

Je kunt je ook afvragen tegen welk soort speler je het wilt opnemen.
Naar een voorbeeld van ons practicum Java: een domme speler, die random een zet doet of een slimme speler die kijkt welk van de volgende zetten winnend voor hem is.

[Robtimus]

Wat natuurlijk kan leiden tot Player als abstract class / interface, met als subclasses HumanPlayer en ComputerPlayer, misschien zelfs meerdere ComputerPlayer classes voor de verschillende niveaus.

[Verwijderd]

Mijn standaard methode is om het verhaal eens op te schrijven. Vervolgens stel ik dat alle onderwerpen klasses zijn. De bulk van werkwoorden is methode, hoewel dingen als "heeft" en "is" zich tot relaties laten vertalen. Vervolgens klopt van mn verhaal niet zo veel meer, maar dan schrijf ik het nog eens op aan de hand van nieuwe inzichten. Bij latere verhaaltjes is het mogelijk eerder gevonden klasses te degraderen tot attributen van andere klasses.
Vaak zijn er een aantal OO modellen mogelijk, elk met zijn eigen sterktes en zwaktes.

Uit je voorbeeld: mijn verhaal versie 1.
Elke speler heeft 20 schijfjes. Een speler ziet het bord en plaatst er schijfjes. Over het plaatsen zijn bepaalde spelregels. Er zijn menselijke spelers en AI spelers. En tenslotte wint iemand het spel.

Wat spelers aangaat zie ik het dan als volgt:
CGeneriekeSpeler
<- CMenselijkeSpeler
<- CAISpeler
"Schrijfjes hebben" en "schrijfjes plaatsen" zie ik als methode van CGeneriekeSpeler. "Hebben" duidt op containment. "Plaatsen" zou het goed doen als methode van CGeneriekeSpeler. Als deze methode abstract is, kunnen beide afgeleide klasses voorzien in een eigen methode hoe ze besluiten nemen. AHA, nieuw werkwoord "besluiten" --> nieuw verhaaltje.

etc etc

[Alarmnummer]

@Bloog: daarmee krijg je wel een initieel object model. Bij complexere objecten (of bij objecten die meer in frameworks/utils komen begin ik vervolgens te kijken naar bepaalde stukken functionaliteit binnen dat object). Als je bv een Bank object hebt, kan je kijk naar een valideercreditcardnummer, valideerisleninggeldig, of een hoeveelgeldverstrekkenwepolicy. Op die manier krijg je hele flexibele objecten met heel erg duidelijk gescheiden functionaliteit.

Dit fenomeen staat trouwens bekend als dependency injection en je krijgt er ook prachtig testbare code mee.

[ Voor 8% gewijzigd door Alarmnummer op 08-02-2005 21:55 ]

[Soultaker]

Leuk; voor dit concept heb ik ook al eens een klassenstructuur ontworpen (maar dan iets algemener). Ik gebruik een aantal verschillende criteria bij het opsplitsen van functionaliteit (want daar komt het indelen van een klassenstructuur op neer):

• verschillende 'concepten' moeten aparte typen worden
Een munt is wat anders dan een speler, en een spelbord is weer wat anders dan die eerste twee. Dat moeten dus aparte typen worden (in Java kun je er dan bijna allen maar klassen van maken; het is heel vervelend als je eerst een basic type had gekozen en er later toch een klasse van wil maken).

Dit criterium is vaak het beginpunt; je begint met de 'dingen' in de wereld die je wil modeleren onder te verdelen in concepten en daar klassen voor te bouwen. Daarna ga je nadenken over communicatie tussen de klassen en functionaliteit.

• splits een enkel 'concept' op in verschillende soorten van functionaliteit
Als je een spelbord hebt waar stukken op staan en die je op het scherm kunt weergeven, dan lijkt dat misschien één concept, maar feitelijk is er een duidelijk onderscheid tussen de functionaliteit van een object waarin de posities van stukken worden opgeslagen en een klasse die de interactie met de gebruiker regelt. Sterker nog: voor de eerste functie is de tweede niet vereist, maar omgekeerd wel.

In zo'n situatie is het dus wenselijk om typen op te splitsen; in het voorbeeld in een Bord (waar alleen informatie over het 'logische' spelbord wordt opgeslagen) en een BordControl (ofzoiets) die de (grafische) interactie levert. Dit heeft als voordeel dat je verschillende soorten visualisaties zou kunnen maken (eentje voor AWT/Swing en eentje voor text-mode in de console, bijvoorbeeld) en dat je bovendien de grafische elementen buiten beschouwing kan laten als je een AI-speler ontwerpt (want die is alleen geïnteresseerd in de 'logische' inhoud van het spelbord).

• breng methoden die los staan van de klasse waar ze bij horen (en vaak op verschillende objecten werken) onder in een aparte klasse
Het is verleidelijk om bijvoorbeeld het kiezen van een zet door de AI-speler onder te brengen in de Bord-klasse (want dan kun je naar de toestand van het bord kijken), maar dat is eigenlijk niet handig, omdat je om de functionaliteit te wijzigen dan een afgeleide klasse moet maken van Bord, wat conceptueel fout is, omdat je het Bord helemaal niet veranderd! Dat soort algoritmen moeten dus in een eigen klasse komen (ook al hebben ze zelf weinig 'eigen' staat om op te slaan).

Voor je AI-algoritmen wil je dus een aparte klasse hebben, eventueel per soort algoritme een aparte klasse zodat je ze uitwisselen en onderling combineren (bijvoorbeeld zoekstrategie en evaluatiefunctie onafhankelijk kiezen).
[insert uitleg van strategy patterns door Alarmnummer here]

[Verwijderd]

Het lijkt me dat TS gebaat is met een methode een initieel ontwerp te maken bij een "eenvoudig" probleem. Grote aangelegenheden en toepassing van patroontjes komen later wel. Mediator en Strategy zijn niet de gemakkelijkste patronen om even op te pakken.

Wat kalken jullie achterop het sigarenkistje ?

[Verwijderd]

het probleem dat ik hierbij steeds ondervindt is of een attribuut nu een primitief type is of een klasse dat vindt ik vrij verwarrend en ik vind hier ook geen goede methode

[Alarmnummer]

Alles is een class tenzij er ook een primitief type voor is Primitieve types zijn een noodzakelijk kwaad. Vanuit oo oogpunt zou alles een object moeten zijn, maar dan krijg je enorme performance problemen.

[ Voor 55% gewijzigd door Alarmnummer op 09-02-2005 10:24 ]

[Verwijderd]

ja maar bvb kleur kan in sommige klassen een primitief type zijn en in sommige andere klassen kan die kleur dan een klasse moeten zijn soms wel verwarrend althans in mijn "beginners ogen" toch :-)

[.oisyn]

Verwarrend is geen hoofdletters en leestekens gebruiken zodat je niet weet waar de ene zin eindigt en de andere begint .