Page History

Selv om et slikt enkelt spill kan implementeres med én klasse, så legger vi opp til en klassisk todeling i én hovedprogram-klasse, som håndterer kommunikasjone med brukeren, og én logikk-klasse, som håndterer spill-logikken. Dersom logikk-klassen gjøres anvendelig og generell nok, vil en senere kunne gjenbruke den i en grafisk versjon. Todelingen illustreres under med et objektdiagram:

...

class MemoryProgram {
}
class Memory {
	expectedItems	// list of numbers 1-9
	acceptedCount	// position in list
	nextItem()		// adds item to list
	acceptItem()	// accepts (or rejects) item
}

MemoryProgram -right-> Memory: memory

actor bruker
MemoryProgram -> Memory: nextItem()
Memory --> MemoryProgram: 3
MemoryProgram -> bruker: "Element nr. 1 er 3"
MemoryProgram -> bruker: "Gjenta element nr. 1 av 1"
bruker --> MemoryProgram: 3
MemoryProgram -> Memory: acceptItem()
Memory --> MemoryProgram: ok og ferdig
MemoryProgram -> Memory: nextItem()
Memory --> MemoryProgram: 4
MemoryProgram -> bruker: "Element nr. 2 er 4"
MemoryProgram -> bruker: "Gjenta element nr. 1 av 2"
bruker --> MemoryProgram: 3
MemoryProgram -> Memory: acceptItem()
Memory --> MemoryProgram: ok, men ikke ferdig
MemoryProgram -> bruker: "Gjenta element nr. 2 av 2"
bruker --> MemoryProgram: 4
MemoryProgram -> Memory: acceptItem()
Memory --> MemoryProgram: ok og ferdig
MemoryProgram -> Memory: nextItem()
Memory --> MemoryProgram: 4

object "Memory" as memory1 {
	expectedItems = []
	acceptedCount = 0
}
object "Memory" as memory2 {
	expectedItems = [3]
	acceptedCount = 0
}
Memory1memory1 -down-> Memory2memory2: nextItem() => 3
object "Memory" as memory3 {
	expectedItems = [3]
	acceptedCount = 1
}
Memory2memory2 -down-> Memory3memory3: acceptItem() => ok og ferdig
object "Memory" as memory4 {
	expectedItems = [3, 4]
	acceptedCount = 0
}
Memory3memory3 -down-> Memory4memory4: nextItem() => 4
object "Memory" as memory5 {
	expectedItems = [3, 4]
	acceptedCount = 1
}
Memory4memory4 -down-> Memory5memory5: acceptItem() => ok, men ikke ferdig
object "Memory" as memory6 {
	expectedItems = [3, 4]
	acceptedCount = 2
}
Memory5memory5 -down-> Memory6memory6: acceptItem() => ok og ferdig
object "Memory" as memory7 {
	expectedItems = [3, 4, 7]
	acceptedCount = 0
}
Memory6memory6 -down-> Memory7memory7: nextItem() => 7

I sekvensdiagrammet har vi satt navn på to tjenester som Memory-objektet må tilby: nextItem() genererer nye tall i sekvensen, og acceptItem() tar imot et nytt tall (fra brukeren) og sjekker det mot fasiten. Det er dessuten underforstått at Memory må huske både tall-sekvensen og hvor langt brukeren har kommet i å gjenta den, som angitt i klassediagrammet med henholdsvis attributtene expectedItems og acceptedCount. To av de mulige svarene fra acceptItem() er angitt som ok og ferdig og ok, men ikke ferdig. Dette er ikke gyldig java, så når vi koder metoden, så må vi finne passende verdier å returnere for disse to tilfellene, i tillegg til den tredje muligheten, som er feil.

Dette er et godt utgangspunkt for å begynne å kode, Dette er et godt utgangspunkt for å begynne å kode, og for noen vil det være det meste effektive. Men er man fortsatt usikker på hvordan den interne tilstanden håndteres av metodene, så kan et objekttilstandsdiagram være nyttige, siden det illustrerer effekten av metodekall på den interne tilstanden, ikke bare sekvensen av kall. Et slikt diagram er vist til høyre for tilstandsdiagrammet, basert på samme sekvens av kall.

...

Scanner scanner = new Scanner(System.in);
do {
	Memory memory = new Memory();				// new game instance
	while (true) while (true) {								// repeat as long as the user does not make a mistake
		int nextItem = memory.nextItem();		// extend sequence with another value
		System.out.println("\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n");	// scroll previous dialog away
		System.out.println("Element nr. " + memory.getItemCount() + " er " + nextItem);
		Boolean result = null;
		do {									// get another number from the user
			System.out.println("Gjenta element nr. " + (memory.getAcceptedCount() + 1) + " av " + memory.getItemCount());
			int nextInt = Integer.valueOf(scanner.nextLine().trimnextInt());
			result = memory.acceptItem(nextInt);	// check item
		} while (result == null);					// repeat until there is a definite result, either a mistake or a complete and correct sequence
		if (result == Boolean.FALSE) {				// if the user made a mistake, break out of loop
			System.out.println("Feil, den lengste sekvensen du klarte var på " + (memory.getItemCount() - 1) + " elementer.");
			break;
		}
	}
	System.out.println("Vil du prøve på nytt (ja/nei)?");
} while (scanner.nextLinenext().trim().equals("ja"));	// repeat as long as the user wants to play another game
scanner.close();

Merk at vi her har brukt to getter-metoder i Memory som ikke er angitt i diagrammene eller koden, nemlig getItemCount() og getAcceptedCount().

Dette er ren prosedyre-orientert kode og må plasseres inn i Dette er ren prosedyre-orientert kode og må plasseres inn i en metode i hovedprogram-klassen MemoryProgram. Strengt tatt kan dette være main-metoden som startes opp ved kjøring av Java-programmer, men i et objektorientert hovedprogram bruker vi main-metoden til kun å opprette hovedprogram-objektet, som her er en instans av MemoryProgram og så kjøre en run-metoden, som inneholder koden over:

public class MemoryProgram {

	private Memory memory;

    privatepublic void init() {
		memory = new Memory();	// new game instance
    }

    public void run() {
		... // insert the code above
    }

	// entry point for Java program    
    public static void main(String[] args) {
        new MemoryProgram().run();	// instantiate program object and call its run() method
    }
}

I versjon 2 av Memory-programmet så ser vi på hvordan koden kan gjøres litt mer generell og gjenbrukbar. I versjon 3 bytter vi ut det tekstlige brukergrensesnittet med et minimalistisk grafisk grensesnitt bygget på JavaFX-rammeverket. Dette videreutvikles i versjon 4 til et rikere brukergrensesnitt, hvor flere JavaFX-mekanismer prøves ut.