Et annet navn til blackjack-forhandleren

Et annet navn til blackjack-forhandleren h1>

Fa via App Store Les dette innlegget i var app!

Organiserer klasser for Blackjack-spill.

Jeg ma skrive et Blackjack-spill for college ved hjelp av behandlingsspraket. Det ma gjores i en streng objektorientert tiln rming, sa jeg kan ikke gjore en gjenstand for en klasse i en annen klasse med mindre det er noen sammenheng.

Vi ma bruke et spillergrensesnitt:

Jeg har gjort et storyboard for spillet:

Jeg planlegger a ha en klasse som heter ScoreTable hvor jeg kan holde og vise resultatene og en knappeklasse hvor jeg kan tegne knappene.

Hva slags klasser skal jeg ha? Skal jeg ha en ScoreTable klasse som implementerer Player, og ogsa en frittstaende Button-klasse?

Du begynner a blande forretningslogikken med brukergrensesnittet. Du bor (kunne) lage en «spilldriver» -klasse uten hensyn til brukergrensesnittet. Du vil holde din GUI-kode skilt fra din spilllogikkode. Og et annet OO-paradigme er a skape nye objekter separat og sende dem inn der de blir brukt.

Jeg ser en spillklasse («Forhandler» kan v re et bedre navn) som handterer kortene, handler dem til spillere, osv. Sa din ScoreTable-klasse-ledning er det knapper til spillmetodene. For eksempel kan en «Deal» -knapps klikkhendelsehandler v re Game.DealCards ().

pseudokode for ideen:

Klasser og deres interaksjon reflekterer virkeligheten. Skriv kode pa den maten. DVS. En «Forhandler» avtaler «Kort» s fra en «CardDeck» til «Player» s. (Na liker jeg «Forhandler» bedre enn «Spill» som et klassenavn). Derfor ma spillet ha (referanser til) spilleren s, sa vi overforer spillobjekter til spillkonstruktoren. Tenk i forhold til ScoreTable bare a vise spillet, IKKE egentlig a spille spillet. Spillklassen spiller spillet. Dermed ma ScoreTable samhandle / kommunisere med Game for a vise hva som skjer. Tenk pa ScoreTable som a fortelle spillet hva du skal gjore og spillet gjor det. For eksempel klikker du pa «Hit Me» (ScoreTable), og det brann Method.DealCard () -metoden. BlackJackTable lyder bedre for meg enn ScoreTable for det klassenavnet.

Kan jeg fa en ScoreTable-klasse som implementerer spiller og en frittstaende knappeklasse?

Ikke gjor dette. Tenk i virkelige liv for a holde ting rett. En ScoreTable er en spiller? Det gir ikke mening. En ScoreTable ma vise ting pa skjermen sa det er (arver fra) et vindu – uansett hvilken klasse som er i Java.

Hva slags klasser skal jeg ha?

Jeg ser en ScoreBoard-klasse. Diagrammet inspirerte tanken. Diagrammet antyder direkte at klassen vil ha en rekkevidde (av hender) som hvert element innehar sluttresultatet for begge spillerne. Denne datastrukturen kartlegger sa klart ditt brukergrensesnitt. Jeg ser det som en egen klasse fordi den holder poengsum for begge spillerne, sa det er upassende a v re inne i (individuell) Spillerklasse. En spiller kan ha sin score (hand) for dagens spill, men ikke tidligere spill, og absolutt ikke de siste spillene til en annen spiller.

Kortdekk – det er en bunke med kort, det er ikke et kort. Og jeg mener «stable» i maten den oppforer seg pa. Menneskelig – En spiller som er dum (vi skal klikke pa knapper for a fortelle henne hva de skal gjore). Datamaskin – en spiller som kjenner seg selv nar de skal holde dem og nar de skal kaste dem Game – forhandleren egentlig. Shuffles og avtaler kort. ScoreTable – viser hva som skjer. «Kontrollerer» spillet via knappeklikk, etc. ScoreCard – holder historien over tidligere spillresultater.