Der er meir enn éin måte å designa systemet på, men nokre drag går att i nesten alle dei ryddige løysingane. Der er tre superklasser som nesten alle har
Game er ein nykelklasse. Ein Game-instans er ei spelrunde, som er ei enkel og avgrensa hending i røynda, og som lett kan modellerast. Kvar spelrunde har ei samling kupongar som er innlevert, ein tidsfrist for innlevering, tidspunkt for trekkjing, eit resultat, premiar og vinnarar. Dersom ein ynskjer å lagra historiske data, kan ein lagra heile spelrunda (Game-instans) og alt ligg på ein plass.
Koden vert mykje enklare om de får ein god modell for denne Game-klassa, og unngår å måtte bla gjennom globale lister med spelarar, kupongar, etc. Game-klassa er chef for ein stor del av systemet, så fokuser på å få ho i orden.
Kupongen, Ticket, er deltakinga til ein spelar. Kvar spelrunde må ha kontroll på dei kupongane som tek del (t.d. ArrayList). Kvar kupong hev ein spelar (som har levert han inn) og det fell i kupongen sitt ansvarsområde, men det er ikkje vesentleg denne veka.
Ein kupong hev fleire rekkjer og kvar rekkje har ein sjølvstendig sjanse til å vinna ein premie. Kupongen må ha rede på dei rekkjene sine (gjerne ein ArrayList).
Der er eit par metodar som er uunnverlege og som krev litt tankearbeid. Det gjeld i alle fall
Dei to fyrste har dei fleste på plass frå i haust, men den tredje kan krevja litt arbeid. Kva klasse bør han liggja i? Det er viktig at han vert skrive for å minimera kobling mellom klassene. Ein kan ikkje unngå kobling mellom dei to klassene som vert samanlikna, men ein bør ikkje ha meir enn det.
Det er viktig å gjera alt enklast mogleg. Den grunnleggjande strukturen med klassene nemde over må på plass. Denne strukturen kan haldast enkel ved å skjula detaljana inni ei hovudklasse, og klart definera ansvarsområdet for kvar klasse.
Eg vil anbefala å gå fram slik: