Page History

...

Expand

title	Del 3 - Introduksjon av et Dice-grensesnitt

Det finnes flere måter å implementere Dice-klassen og alle dens metoder, med ulike fordeler og ulemper. En måte å tillate bruk av flere implementasjoner er å gjøre om Dice til et grensesnitt og så ha en eller flere implementasjonsklasser, hvor den eksisterende Dice-klassen blir en av disse:

public interface Dice {

...

}

public class DiceImpl1 implements Dice { ... tilsvarer løsningen i deloppgavene 1-6 ... }

public class DiceImpl2 implements Dice { ... alternativ løsning ... }

Navnene på implementasjonsklassene kan selvsagt være mer forklarende.

Oppgave a) - Dice-grensesnittet (4 poeng)

Dette var en flervalgsoppgave med to spørsmål og valg av ett av flere alternativer.

Spørsmål 1: Tre alternative grensesnitt er foreslått, basert på den nåværende Dice-klassen:

Code Block

// Alternativ 1, alle metoder og konstruktører:
public interface Dice ... {
    static Collection<Integer> randomDieValues(int dieCount);
    Dice(Collection<Integer> dieValues, int score);
    Dice(int dieCount);
    Dice(Dice dice, int score);
    static Dice valueOf(String s);
    int getScore();
    void setScore(int score);
    int getDieCount();
    int getDieValue(int dieNum);
    int getValueCount(int value);
    boolean contains(Dice dice);
    Dice add(Dice dice);
    Dice remove(Dice dice);
}
 
// Alternativ 2, alle metoder:
public interface Dice ... {
    static Collection<Integer> randomDieValues(int dieCount);
    static Dice valueOf(String s);
    int getScore();
    void setScore(int score);
    int getDieCount();
    int getDieValue(int dieNum);
    int getValueCount(int value);
    boolean contains(Dice dice);
    Dice add(Dice dice);
    Dice remove(Dice dice);
}
 
// Alternativ 3, utvalgte metoder:
public interface Dice ... {
    int getScore();
    void setScore(int score);
    int getDieCount();
    int getDieValue(int dieNum);
    int getValueCount(int value);
    boolean contains(Dice dice);
    Dice add(Dice dice);
    Dice remove(Dice dice);
}

Spørsmål 2: Den opprinnelige Dice-klassen implementerer Iterable<Integer>. Spørsmålet er hvordan dette skal håndteres ved overgangen til et Dice-grensesnitt.

Dice-grensesnittet må utvide (extends) Iterable<Integer>.
Dice-grensesnittet må både utvide (extends) Iterable<Integer> og liste opp metoden(e) fra Iterable.
Dice-grensesnittet må liste opp metoden(e) fra Iterable.
Dice-grensesnittet må utvide (extends) Iterable<Integer> og kan liste opp metoden(e) fra Iterable.

Expand

title	LF

På det første spørsmålet er alternativ 3 riktig, for et grensesnitt skal ikke ha konstruktører og statiske metoder

På det andre spørsmålet er alternativ 4 riktig, for et grensesnitt kan gjenta metoder fra et grensesnitt det utvider, men må ikke. Her skulle jeg ønske det gikk an å gi noe for alternativ 1.

Oppgave b) - Arv (6 poeng)

Hvis en har flere implementasjoner av det nye Dice-grensesnittet, så kan en regne med at visse deler av disse vil bli nokså eller helt like.

Ett aspekt som typisk vil bli (nokså) likt er håndtering av poengene (score). Forklar med tekst og/eller kode hvordan du vil håndtere det vha. arvingsmekanismen, slik at løsningen tillater stor grad av gjenbruk av kode i subklasser og blir ren og ryddig.

Expand

title	LF

Her er poenget å skille ut det som har med score å gjøre i en abstrakt superklasse, nemlig feltet score, (den delen av) konstruktøren som tar inn og setter score og getScore og setScore. Dette er viktigst.

Hvis en lar den abstrakte superklassen implementere Dice-grensesnittet evt. deklarer en del av Dice sine metoder som abstrakte metoder, så kan enda flere metoder implementeres, f.eks. trenger toString og getValueCount bare getDieCount og getDieValue. En trenger ikke implementere disse, men forklare at det går an og vil være lurt.

Code Block

public abstract class AbstractDice implements Dice {

   private int score = -1;
 
   protected AbstractDiceImpl(int score) {
     this.score = score;
   }
 
   @Override
   public String toString() {
      ... kan implementeres fordi getDieCount og getDieValue er deklarert (selv om de er abstrakte) ...
   }
 
   // implementasjon som bare er avhengig av at Dice utvider Iterable
   public int getValueCount(int value) {
      int count = 0;
      // Iterable er implementert!
      for (int dieValue : this) {
         if (dieValue == value) {
            count++;
         }
      }
      return count;
   }
 
   @Override
   public int getScore() {
      return score;
   }
 
   @Override
   public void setScore(int score) {
      if (this.score >= 0) {
         throw new IllegalStateException("Cannot set score more than once");
      }
      this.score = score;
    }
}

Oppgave c) - Delegering (10 poeng)

Dicesin add-metode skal lage en ny Dice-instans (altså instans av en klasse som implementerer Dice) som kombinerer terningverdier fra to andre Dice-instanser (this og argumentet). En kan tenke seg at metoden returnerer en instans av en ny Dice-implementasjon kalt DiceAdder, som bruker delegering. Den vil ha to Dice-felt og en konstruktør som tar inn to Dice-instanser:

DiceAdder(Dice dice1, Dice dice2) { ... feltene settes her ... }

Hver Dice-metode kan da bruke/delegere til disse to Dice-instansene i sin løsning, f.eks. vil getDieCount()returnere summen av getDieCount()for hver av de to Dice-instansene:

public int getDieCount() {

return dice1.getDieCount() + dice2.getDieCount();

}

Forklar med tekst og/eller kode hvordan delegeringsteknikken vil bli brukt i følgende metoder i en slik DiceAdder-klasse: getDieValue, getValueCount, contains, add og remove. Kommenter spesielt hvis delegeringsteknikken ikke passer for en spesifikk metode!

Expand

title	LF

Her ønsker vi kode for de som er greie å implementere med delegering, og tekst som forklarer hvorfor det ikke er greit. Det går også an med en blanding. Vi sa ingenting i oppgaven om håndtering av score, så det dropper vi helt her.

Code Block

public class DiceAdder implements Dice {
 
   private final Dice dice1, dice2;
 
   public DiceAdder(Dice dice1, final Dice dice2) {
      super(score);
      this.dice1 = dice1;
      this.dice2 = dice2;
   }
 
   @Override
   public int getDieCount() {
      // Rett frem bruk av delegering, som vist i oppgaveteksten
      return dice1.getDieCount() + dice2.getDieCount();
   }
 
   @Override
   public int getDieValue(final int dieNum) {
      int dieCount1 = dice1.getDieCount();
      // Vi henter de første verdiene fra dice1,
      // så sjekker om indeksen er lav nok
      if (dieNum < dieCount1) {
         return dice1.getDieValue(dieNum);
      }
      // De neste verdiene hentes fra dice2, med (ned)justert indeks 
      return dice2.getDieValue(dieNum - dieCount1);
   }
 
   @Override
   public int getValueCount(final int value) {
      // Rett frem bruk av delegering, som vist i oppgaveteksten
      return dice1.getValueCount(value) + dice2.getValueCount(value);
   }
 
   @Override
   public Dice add(final Dice dice) {
      // Vi lager en instans av denne klassen,
      // den representerer jo nettopp to Dice slått sammen
      return new DiceAdder(this, dice);
   }
 
   @Override
   public boolean contains(final Dice dice) {
      // Dette er ikke så rett frem, men
      // algoritmen bruker delegering til getValueCount
      for (int dieValue = 1; dieValue <= 6; dieValue++) {
         if (dice.getValueCount(dieValue) > getValueCount(dieValue)) {
            return false;
         }
      }
      return true;
   }
 
   @Override
   public Dice remove(final Dice dice) {
      // Denne er ikke rett frem i det hele tatt, så den utelater vi...
   }
}

Expand

title	Del 4 - Farkle-regler og FarkleRound-klassen

Expand

Så langt har koden vært relativt uavhengig av typen terningspill. I denne deloppgaven handler det om en runde i Farkle-spillet. I en slik runde så akkumuleres det poeng ved at en gjentatte ganger kaster terninger, og sparer på en eller flere poenggivende terningkombinasjoner.

Reglene for hvilke kombinasjoner som gir poeng varierer noe mellom ulike varianter av Farkle, men en får typisk poeng for tre eller flere like, og for femmere (50 poeng pr. stk) og enere (100 poeng pr. stk). En tenker seg at dette beregnes av en metode tilsvarende computeDiceScoresfra deloppgave 8 om totalpoengberegning.

Etter hvert kast har en tre tilfeller/muligheter:

Hvis ingen terningkombinasjoner gir poeng, så er runden over og en mister alle poengene en evt. har akkumulert.
En kan velge å stoppe og får poeng for terningkombinasjonene en har spart så langt og for de gjenværende som en akkurat kastet.
En kan velge å legge til side en eller flere poenggivende terningkombinasjoner, og få poeng for dem, og så kaste resten. Hvis en beholder alle terningene en kastet så det ikke er noen igjen å kaste, så kan en kaste alle på nytt.

For hvert kast så får en de samme tre mulighetene. Avveiningen i spillet er altså om en skal beholde poengene en har fått så langt, eller kaste på nytt for å få flere poeng, men risikere å miste alle.

Her er noen eksempler som illustrerer reglene:

En kaster 2, 3, 3, 4 og 4. Runden stopper opp av seg selv, med 0 poeng som resultat :-(
En kaster 2, 3, 4, 5 og 5. En legger til side en 5-er for 50 poeng, og kaster de fire gjenværende terningene. En får 1, 3, 5 og 6. En legger til side 1-eren og 5-eren for 150 nye poeng, altså 200 til sammen så langt, og kaster de to terningene som er igjen. En får da 4 og 4, og mister alle poengene :-(
En kaster som i pkt. 3, men stopper før det siste kastet og får altså 200 poeng for runden :-) // Her skulle det stått "som i pkt. 2"
En kaster som over, men er heldig og får to 5-ere for 50+50 poeng i de siste kastet og kan kaste alle på nytt. En får da 1, 1, 1, 4 og 6, sparer de tre 1-erne for 1000 poeng (spesialregel for poenggiving i Farkle) og stopper. Runden gir da 200+50+50+1000 poeng :-)

Et forslag til realisering av en klasse som håndterer en Farkle-runde, er vist under. Noen deler er imidlertid utelatt...

Code Block


/**
 * Represents a round of Farkle, where a player throws and keeps dice,
 * until s/he either "bank", i.e. save your points, or
 * farkle, i.e. get no points in a throw and hence looses all gathered points.
 * During and after a finished round, kept sets of dice and their scores are available.
 * During a round, the remaining dice are also available.
 */
public class FarkleRound {
    private int dieCount;
    private Collection<Dice> kept = new ArrayList<>();
    private Dice currentDice;
 
    /**
     * Initializes a new round, where dieCount number of dice is immediately rolled.
     * Note that the round may be immedielately finished, if the initial roll give no points.
     * @param dieCount the number of dice rolled
     * @param scoring the object responsible for computing the score
     */
    public FarkleRound(int dieCount) {
        this.dieCount = dieCount;
        roll(dieCount);
    }
    private void roll(int dieCount) {
        this.currentDice = new Dice(Dice.randomDieValues(dieCount), -1);
        if (computeDiceScores(currentDice).isEmpty()) {
            this.kept.clear();
            this.currentDice = null;
        }
    }
    private Collection<Dice> computeDiceScores(Dice dice) {
       ... implemented earlier in this exam ...
    }
 
    /**
     * @return true of the round is finised, false otherwise
     */
    public boolean isFinished() {
        return this.currentDice == null;
    }

    /**
     * Called when the player decides to stop and secure points.
     * Finishes the round, by keeping all scoring Dice, as computed by the scoring object.
     */
    public void bank() {
        if (isFinished()) {
            throw new ... which exception class ? ...
        }
        this.kept.addAll(computeDiceScores(currentDice));
        ... put this object in a state that indicates this round is finished ...
    }
 
    /**
     * Called when the player decides to keep specific dice and roll the rest.
     * All the dice kept must be scoring ones, but not all scoring dice need to be kept.
     * @param dice the dice to keep, the rest of the current dice should be thrown.
     */
    public void keepAndRoll(final Dice dice) {
        if (isFinished()) {
            throw new ... which exception class ? ...
        }
        if (! currentDice.contains(dice)) {
            throw new ... which exception class ? ...
        }
        final Collection<Dice> scores = computeDiceScores(dice);
        if (scores.stream().mapToInt(Dice::getDieCount).sum() != dice.getDieCount()) {
            throw new SomeKindOfException("You can only set aside dice that contribute to the score");
        }
        kept.addAll(scores);
        currentDice = currentDice.remove(dice);
        // roll remaining dice or all, if there are none left
        ... what code needs to be here ? ...
    }
}

Oppgave a) - final (2 poeng)

Dette var en flervalgsoppgave med ett spørsmål og to korrekte alternativer og ett galt et.

Spørsmål: Hvilke, om noen, av feltene øverst i FarkleRound-klassen kan ha modifikatoren final?

dieCount
kept
currentDice

Expand

title	LF

Her er 1 og 2 riktig og 3 er gal, siden 1 og 2 bare settes én gang (i initialiseringsdel av deklarasjon eller i konstruktør). Riktignok endres innholdet i kept-lista, men det er det samme objektet som endres hele tiden.

Oppgave b) - Kode i bank (2 poeng)

Dette er en tekstinnfyllingsoppgave som vurderes automatisk.

Spørsmål: Nederst i bank-metoden er en kodelinje erstattet med "... put this object in a state that indicates this round is finished ...". Skriv inn den korrekte kodelinjen. Koden må være korrekt, komplett og konsis, uten kommentarer, siden den sjekkes automatisk.

Expand

title	LF

Her er poenget å skjønne at isFinished-metoden i FarkleRound sjekker om currentDice er null, så koden må sette dette feltet til null.

Alternativene som ble godkjent var currentDice == null med eller uten this foran og ; bak. Mellomrom rundt == ignoreres.

Oppgave c) - Unntakstyper (3 poeng)

Dette er en flervalgsoppgave med tre spørsmål.

I keepAndRoll-metoden utløses unntak i tre tilfeller.

Spørsmål 1: Hvilken av disse unntakstypene passer i det første tilfellet?

Exception
RuntimeException
IllegalArgumentException
IllegalStateException

Spørsmål 2: Hvilken av disse unntakstypene passer i det andre tilfellet?

Exception
RuntimeException
IllegalArgumentException
IllegalStateException

Spørsmål 3: I det tredje tilfellet bruker vi unntakstypen SomeKindOfException, som er tenkt som en egendefinert unntakstype. Hvilken unntakstype bør brukes som superklassen til SomeKindOfException?

Exception
RuntimeException
IllegalArgumentException
IllegalStateException

Expand

title	LF

Svaret på det første spørsmålet er IllegalStateException, fordi metoden skal ikke kalles (uansett hva argumentet er) når runden er ferdig.

Svaret på de to neste IllegalArgumentException, fordi metoden det (primært) handler om validering av argumentet.

Oppgave d) - Kode i keepAndRoll (2 poeng)

Nederst i keepAndRoll-metoden er én eller flere kodelinjer erstattet med "... what code needs to be here ? ...". Skrive linjen(e) som mangler. Koden vil bli lest av sensor.

Expand

title	LF

Her er poenget at vi må avslutte metoden med å kalle roll, og må finne ut om vi skal kaste de som er igjen (hvis det er noen terninger igjen) eller all.

Code Block

int dieCount2 = currentDice.getDieCount();
if (dieCount2 == 0) {
   dieCount2 = this.dieCount;
}
roll(dieCount2);

// Evt. bareint dieCount2 = currentDice.getDieCount();
roll(dieCount2 == 0 ? this.dieCount : dieCount2);

Page tree

Versions Compared

Old Version 5

New Version 6

Key

Oppgave a) - Dice-grensesnittet (4 poeng)

Oppgave b) - Arv (6 poeng)

Oppgave c) - Delegering (10 poeng)

Oppgave b) - Kode i bank (2 poeng)

Oppgave c) - Unntakstyper (3 poeng)

Oppgave d) - Kode i keepAndRoll (2 poeng)