...
Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Oppgave a) - DiceScore-klassen (6 poeng)Skriv ferdig DiceScore-klassen, med egnede felt, konstruktørkode og tilgangsmetoder, med utgangspunkt at DiceScore-objekter ikke skal kunne endres etter at de er opprettet.
Oppgave b) - SingleValue-klassen (6 poeng)Skriv kode for klassen SingleValue(enkeltverdi), som implementerer DiceScorermed følgende logikk: For et Dice-argument som ikke inneholder den spesifikke verdien returneres null. Ellers returneres et (nytt) DiceScore-objekt med riktige verdier satt. Merk at klassen bare gir poeng for én av den angitte verdien, selv om Dice-objektet inneholder flere av denne verdien. Eksempel: Et SingleValue-objekt opprettet med new SingleValue(5, 50), vil gi 50 poeng for et Diceobjekt med én eller flere femmere. DiceScore-objektet som returneres skal inneholde et Dice-objekt med bare én femmer og (poeng)tallet 50.
Oppgave c) - Straight-klassen (8 poeng)Skriv kode for klassen Straight(alle terningene utgjør en serie), som implementerer DiceScorermed følgende logikk: For et Dice-argument uten straightreturneres null. Ellers returneres et (nytt) DiceScore-objekt med riktige verdier satt. Poengene som gis er en spesifikk verdi (konstant) som settes når Straight-objektet opprettes. Merk at koden skal virke selv om det er (mange) færre eller flere terninger enn mulige terningverdier (1-6). Et Dice-objekt med bare én terningverdi vil f.eks. alltid gi straight, mens et Dice-objekt med flere enn 6 terningverdier aldri kan gi straight.
Oppgave d) - Nothing-klassen (8 poeng)Skriv kode for klassen Nothing, som implementerer DiceScorer med følgende logikk: Et spesifikt antall poeng gis hvis ingen (andre) poengregler gir poeng. De andre reglene representeres av et sett DiceScore-objekter som gis inn når Nothing-objektet opprettes. Dette gjør at Nothing-klassen ikke trenger å duplisere logikk som er spesifikke for andre regler. Bestem selv typen til diceScorers-argumentet som gis inn. Merk at denne regelen bare gjelder hvis Dice-argumentet til getScore-metoden inneholder minst et visst antall terninger, typisk like mange som brukes i spillet. Dette minsteantallet gis også inn ved opprettelse av Nothing-objektet.
Oppgave e) - Mer om Nothing-klassen (4 poeng)Hva kalles implementasjonsteknikken som det legges opp til at Nothingskal bruke? Begrunn svaret, f.eks. ved å forklare (kort) hva som er karakteristisk for denne teknikken.
Oppgave f) - DiceScorer-deklarasjon (4 poeng) Når en lager en instans av et DiceScorer-objekt og lagrer (referansen til) det i en variabel, så kreves det at variablen er deklarert med en egnet type. Anta at en har følgende deklarasjon med initialisering: ??? aSingleValueObject = new SingleValue(1, 100); Hvilke (tre) mulige typer er det lov å skrive der det står ???, hva er avgjørende for valget og hva vil man typisk bruke?
Oppgave g) - Arv med AbstractScorer (6 poeng) De tre implementasjonene av DiceScorer(SingleValue, Straight og Nothing) har én ting felles. Forklar med tekst og/eller kode hvordan du vil utforme en felles superklasse (f.eks. kalt AbstractScorer) for disse tre, og hvordan de tre implementasjonene vil måtte endres for å fungere som subklasser.
|
Expand | |||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||
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:
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.
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.
Oppgave c) - Delegering (10 poeng)Dice sin 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!
|
...