Dersom du mener at opplysninger mangler i en oppgaveformulering, gjør kort rede for de antagelser og forutsetninger som du finner nødvendig. Hvis du i en del er bedt om å implementere klasser og metoder og du ikke klarer det (helt eller delvis), så kan du likevel bruke dem i senere deler.
En oversikt over klasser og metoder for alle oppgavene er gitt i vedlegg 1. Kommentarene inneholder krav til de ulike delene, som du må ta hensyn til når du løser oppgavene. I tillegg til metodene som er oppgitt, står du fritt til å definere ekstra metoder for å gjøre løsningen ryddigere. Nyttige standardklasser og -metoder finnes i vedlegg 2.
Temaet for oppgaven er et spisested (Diner) og problemstillingen er plassering (Seating) av grupper (Group) av gjester ved bordene (Table).
Group-, Table- og Seating-klassene (vedlegg 1) er såkalte verdi-klasser, med data som skal oppgis ved opprettelsen av objektene og siden ikke skal kunne endres. Group skal inneholde data om antall gjester i gruppa, Table skal inneholde data om antall stoler (capacity) og Seating skal holde rede på bordet en gitt gruppe sitter på. Oppgave a)Skriv ferdig Group og Seating, inkludert nødvendige innkapslingsmetoder.
Oppgave b)En skal ikke kunne ha Seating-objekter for bord som ikke har mange nok stoler til hele gruppa som er plassert der. Skriv koden som trengs for å sikre at denne regelen overholdes.
Oppgave c)Anta at Group hadde en metode for å endre antall gjester. Forklar med tekst og/eller kode hvilke endringer du måtte gjort for å sikre at regelen i b) overholdes.
Oppgave d)I tillegg til antall stoler, skal et bord ha et bordnummer. Dette skal være et unikt løpenummer som ikke oppgis, men settes automatisk av kode i Table-klassen selv når Table-objekter opprettes. Det aller første bordet som lages skal få 1 som nummer, det andre skal få 2 osv. Implementer konstruktøren og annen nødvendig kode, inkludert getNum-metoden!
|
Diner-klassen (vedlegg 1) holder rede på bord (tables) og bordplasseringer (seatings), altså hvilke grupper som sitter ved hvilke bord. Oppgave a)Skriv nødvendige felt-deklarasjoner og konstruktør(er), gitt at spisestedet har mer enn ett bord. Skriv også metodene for å legge til og fjerne bord.
Oppgave b) Skriv metodene isOccupied og getCapacity.
Oppgave c)Bord kan settes samme, typisk for å få plass til store grupper med gjester. Tilsvarende kan bord deles opp, for å unngå at en liten gruppe tar opp et stort bord. Skriv metodene mergeTables og splitTable. I denne omgang skal det ikke registreres hvilke bord som faktisk settes sammen, de forsvinner bare, og må opprettes på nytt ved oppdeling.
Oppgave d)Tegn et objekttilstandsdiagram som illustrerer virkemåten til mergeTables.
Oppgave e)Når gjester skal plasseres må en finne det minste, ledige bordet med nok kapasitet. Skriv metodene hasCapacity og findAvailableTables. Skriv også annen nødvendig kode for å tilfredsstille kravet om sortering av returverdien til findAvailableTables.
Oppgave f)En ny bordplassering registreres i et Seating-objekt. Skriv metodene createSeating, addSeating og removeSeating.
Se også løsningskode på github |
Et problem ved sammensetting og oppdeling av bord er at bordnummeringen blir gal, når logisk sett samme bord opprettes på nytt og får nytt nummer. En måte å håndtere det på er å ha to bord-typer, enkeltbord (SimpleTable) og sammensatt bord (CompositeTable), hvor sistnevnte holder rede på hvilke bord som er satt samme. Den nye versjonen av mergeTable-metoden må altså opprette et CompositeTable som inneholder de to bordene som settes sammen, og splitTable-metoden må skrives om så det deler opp et CompositeTable i de samme to bordene. splitTable-metoden trenger da ikke lenger de to capacity-argumentene fordi de to bordene jo vet sin kapasitet. Oppgave a)Forklar med tekst og kode hvordan du vil bruke arv og/eller grensesnitt, slik at Table fortsatt kan brukes som generell bord-type og SimpleTable og CompositeTable kan håndtere hver sine spesialtilfeller. Forklar kort virkemåten til SimpleTable og CompositeTable.
Oppgave b) Skriv nye versjoner av Diner sine mergeTable- og splitTable-metoder. Merk at den nye splitTable-metoden kun skal ta inn en CompositeTable
Se også løsningskode på github |
Gjester på en Diner tas i mot av en tilhørende GuestManager (se vedlegg 1), som prøver å plassere dem. Dersom det ikke går, så må de vente på at et bord med nok kapasitet blir ledig. GuestManager vil altså ha behov for å følge med på hvordan kapasiteten til Diner-objektet endres. Dette gjøres ved å gjøre Diner sin kapasitet-egenskapen, som returneres av et kall til getCapacity(false), observerbar. Oppgave a)Hva innebærer observerbarhet? Forklar kort med tekst og/eller kode hvordan en gjør en (egenskap i en) klasse observerbar.
Oppgave b)Forklar med tekst og/eller kode hvordan du vil endre Diner slik at GuestManager kan lytte til endringer i capacity-egenskapen (ved å implementere CapacityListener-grensesnittet).
Oppgave c)Forklar med tekst og/eller kode hvordan du vil skrive GuestManager-klassen. Vi forventer ikke komplisert logikk for sammenslåing eller splitting av bord, men de som kom først skal fortrinnsvis få bord først.
Se også løsningskode på github
|
Oppgave a)Er CapacityListener et funksjonelt grensesnitt? Begrunn svaret!
Oppgave b)Skriv (om) en av isOccupied eller getCapacity i Diner slik at den bruker Stream-teknikken og Java 8 sin funksjonssyntaks (hvis du ikke har gjort det fra før, da!).
Oppgave c)Forklar med tekst og/eller kode hvordan du vil teste isOccupied-metoden til Diner i en separat DinerTest-klasse, spesielt hvilke metoder i Diner du vil bruke. Angi om Diner evt. må endres for å være mer testbar.
|
|
interface Iterable<T>
public interface Collection<E> extends Iterable<E>
interface List<E> extends Collection<E>
interface Map<K,V>
interface Stream<T>
class String implements Comparable<String>
class Scanner
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||