Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleDel 1 - Group, Table- og Seating-klassene (15%)

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. 

Expand
titleLF
Code Block
public class Group {
 
       private final int guestCount;
 
       public Group(int guestCount) {
              this.guestCount = guestCount;
       }
 
       public int getGuestCount() {
              return guestCount;
       }
}
 
public class Seating {
 
       private final Table table;
       private final Group group;
 
       public Seating(Table table, Group group) {
              this.table = table;
              this.group = group;
       }
      
       public Table getTable() {
              return table;
       }
      
       public Group getGroup() {
              return group;
       }
}
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.

Expand
titleLF

Følgende kode legges øverst i konstruktøren:

Code Block
if (table.getCapacity() < group.getGuestCount()) {
   throw new IllegalArgumentException("The table is too small for the group");
}

Viktig å utløse unntak, ikke bare en if rundt initialiseringskoden.

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.

Expand
titleLF

Group måtte hatt en referanse til Seating-objektet (eller Table-objektet) som ble satt av Seating, så den kunne kjøre tilsvarende sjekk som over, ved endring av størrelsen. Uten en slik referanse hjelper det ikke å si at en skal sjekke den nye gruppestørrelsen opp mot antall stoler ved bordet. En kan til nød bruk observatør-observert-teknikken, men det er overkill her.

 

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!

Expand
titleLF

Her er poenget at en trenger en global teller, som en får til i Java ved bruk av static. Denne må brukes og økes i Table sin konstruktør.

Code Block
private static int tableCounter = 1; 
 
private final int num;
private final int capacity;
 
public Table(int capacity) {
       this.num = tableCounter++;
       this.capacity = capacity;
}
Expand
titleDel 2 - Diner-klassen (40%)

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.

Expand
titleLF

Vi velger Collection, fordi vi ikke trenger indeksbasert tilgang til elementene. Vi ser ikke noe behov for en konstruktør, siden en like gjerne kan legge til bord ved kall til addTable. Det er greit nok å ha en konstruktør som tar inn et sett bord, f.eks. en varargs som i Table... tables, og da er det viktig å initialisere lokale variabler slik at de ikke kan endres utenifra. Merk at Arrays.asList(...) lager en List som ikke kan endre størrelse, så den kan ikke bruke direkte som verdien til et lokal tables-felt. Hvis en kan gi inn Seating-objekter, så må de valideres, slik at en ikke kan omgå valideringen som vanligvis gjøres i createSeating/addSeating.

Det vil være mulig å bruke én tableSeatings-Map/HashMap i stedet for to lister, hvor tableSeatings.keySet() tilsvarer tables og tableSeatings.values() tilsvarer seatings.

Code Block
private Collection<Table> tables = new ArrayList<>(); 
private Collection<Seating> seatings = new ArrayList<>();
 
public void addTable(Table table) {
 tables.add(table);
}
 
public void removeTable(Table table) {
 if (isOccupied(table)) {
 throw new IllegalArgumentException("Cannot remove an occupied table");
 }
 tables.remove(table); 
}

 

 

Oppgave b)

Skriv metodene isOccupied og getCapacity.

Expand
titleLF
Code Block
public boolean isOccupied(Table table) {
for (Seating seating : seatings) {
              if (seating.getTable() == table) {
                      return true;
              }
       }
       return false;
       // return seatings.stream().anyMatch(s -> s.getTable() == table);
}
      
public int getCapacity(boolean includeOccupied) {
       int capacity = 0;
       for (Table table : tables) {
              if (includeOccupied || (! isOccupied(table))) {
                      capacity += table.getCapacity();
              }
       }
       return capacity;
       // Stream<Table> stream = tables.stream();
       // if (! includeOccupied) {
       //     stream = stream.filter(t -> ! isOccupied(t));
       // }
       // return stream.mapToInt(Table::getCapacity).sum();
}
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.

Expand
titleLF

isOccupied-sjekken kan virke unødvendig, siden den også gjøres i removeTable, men det er best å sjekke på forhånd og ikke underveis, så en ikke utfører endringene delvis (uten å reversere endringene).

Code Block
public void mergeTables(Table table1, Table table2, int lostCapacity) {
       checkNotOccupied(table1);
       checkNotOccupied(table2);
       Table table = new Table(table1.getCapacity() + table2.getCapacity() - lostCapacity);
       removeTable(table1);
       removeTable(table2);
       addTable(table);
}
      
public void splitTable(Table table, int capacity1, int capacity2) {
       checkNotOccupied(table);
       removeTable(table);
       addTable(new Table(capacity1));
       addTable(new Table(capacity2));
}
 
void checkNotOccupied(Table table) {
       if (isOccupied(table)) {
              throw new IllegalArgumentException("The table cannot be occupied");
       }
}
Oppgave d)

Tegn et objekttilstandsdiagram som illustrerer virkemåten til mergeTables.

Expand
titleLF

Den første tilstanden kan inneholde Diner-objekt koblet til to Table-objekter. Transisjonen er et kall til mergeTables. Den andre tilstanden inneholder det samme Diner-objektet koblet til et nytt Table-objekt. capacity-feltene og lostCapacity-argumentet må stemme overens.

PlantUML Macro
object "~#diner : Diner" as diner1 { } object "~#table1 : Table" as table1 { num = 1 capacity = 4 } object "~#table2 : Table" as table2 { num = 2 capacity = 4 } diner1 --> table1: tables diner1 --> table2: tables object "~#diner : Diner" as diner2 { } object "~#table3 : Table" as table3 { num = 3 capacity = 6 } diner2 --> table3: tables diner1 ..> diner2: mergeTables(~#table1, ~#table2, 2)

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.

Expand
titleLF

For hasCapacity er det viktig å ha med en sjekk for om bordet er opptatt, ikke bare sjekke bordets totale kapasitet. For findAvailableTables så er litt av poenget å skjønne at selv om en Collection ikke alltid har en ordning og kan sorteres, så kan en lage or returnere en List som er ordnet og sortert.

Code Block
public boolean hasCapacity(Table table, int capacity) {
       return (! isOccupied(table)) && table.getCapacity() >= capacity;
}
 
public Collection<Table> findAvailableTables(int capacity) {
       List<Table> result = new ArrayList<>();
       for (Table table : tables) {
              if (hasCapacity(table, capacity)) {
                      result.add(table);
              }
       }
       Collections.sort(result);
       return result;
}

Table må implementere Comparable<Table> for at sort-metoden skal kunne brukes og virke. Alternativt kan man lage en (implementasjon av) Comparator<Table>, f.eks. med (t1,t2) -> t1.getCapacity() – t2.other.getCapacity().

Code Block
@Override
public int compareTo(Table other) {
       return getCapacity() - other.getCapacity();
}
Oppgave f)

En ny bordplassering registreres i et Seating-objekt. Skriv metodene createSeating, addSeating og removeSeating.

Expand
titleLF

Her er litt av poenget hvordan en skal håndtere at resultatet fra findAvailableTables er en Collection, som ikke har en ”opplagt” metode for å hente ut første element. Her brukes iterator() og ett kall til next(). Kunne brukt iterator() først og så hasNext() for å sjekke om det er elementer å hente, i stedet for isEmpty (se utkommentert kode). Det er ikke bra å caste til List, selv om en vet at det er en List i praksis, eller endre på retur-typen til findAvailableTables.

 

Det er ikke meningen å utløse unntak i createSeating, hvis ingen bord er ledige, men hvis det gjøres så må addSeating kodes med try/catch og riktig retur-verdi.

Code Block
public Seating createSeating(Group group) {
       Collection<Table> availableTables = findAvailableTables(group.getGuestCount());
       if (availableTables.isEmpty()) {
              return null;
       }
       return new Seating(availableTables.iterator().next(), group);
//     Iterator<Table> tablesIt = availableTables.iterator();
//     return (tablesIt.hasNext() ? new Seating(tablesIt.next(), group) : null;
}
 
public boolean addSeating(Group group) {
       Seating seating = createSeating(group);
       if (seating != null) {
              seatings.add(seating);
              return true;
       }
       return false;
}
 
public void removeSeating(int tableNum) {
       for (Seating seating : seatings) {
              if (seating.getTable().getNum() == tableNum) {
                      seatings.remove(seating);
                      return; // eller break
              }
       }
}
Expand
titleDel 3 - Table, SimpleTable og CompositeTable (15%)

 

.

Oppgave a)

Expand
titleLF

.

 

.

Oppgave b)

.

Expand
titleLF

.

 

Expand
titleDel 4 - (20%)
Oppgave a)

Expand
titleLF

 

Oppgave b)

.

Expand
titleLF
.
Oppgave c)

.

Expand
titleLF
.

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.

Expand
titleLF

SimpleTable og CompositeTable blir subklasser av Table, som selv enten blir et grensesnitt eller en abstrakt klasse med i hvertfall getCapacity-metoden. De to variantene er vist under. SimpleTable kan ta over det meste av Table-koden, evt. arve alt. CompositeTable kapsler inn informasjonen fra mergeTable og bruker de to Table-objektene til å beregne kapasiteten. Alternativt kan Table beholde capacity-feltet og getCapacity()-metoden og de to andre initialiserer capacity med super(...). Vi har her ikke lagt opp til at CompositeTable-objekter skal få et løpenummer, men det er greit å la den funksjonaliteten være en del av en abstract Table-(super)klasse.

Code Block
public class CompositeTable implements Table {
      
       private Table table1, table2;
       private int lostCapacity;
      
       public CompositeTable(Table table1, Table table2, int lostCapacity) {
              this.table1 = table1;
              this.table2 = table2;
              this.lostCapacity = lostCapacity;
       }
 
       public Table getTable1() {
              return table1;
       }
 
       public Table getTable2() {
              return table2;
       }
      
       @Override
       public int getCapacity() {
              return table1.getCapacity() + table2.getCapacity() - lostCapacity;
       }
}
 
public class CompositeTable extends Table {
      
       private Table table1, table2;
      
       public CompositeTable(Table table1, Table table2, int lostCapacity) {
              super(table1.getCapacity() + table2.getCapacity() - lostCapacity);
              this.table1 = table1;
              this.table2 = table2;
       }
 
       public Table getTable1() {
              return table1;
       }
 
       public Table getTable2() {
              return table2;
       }
}

Oppgave b)

Skriv nye versjoner av Diner sine mergeTable- og splitTable-metoder. Merk at den nye splitTable-metoden kun skal ta inn en CompositeTable

Expand
titleLF
Code Block
public void mergeTables(Table table1, Table table2, int lostCapacity) {
       CompositeTable table = new CompositeTable(table1, table2, lostCapacity);
       removeTable(table1);
       removeTable(table2);
       addTable(table);
}
 
public void splitTable(CompositeTable table) {
       removeTable(table);
       addTable(table.getTable1());
       addTable(table.getTable2());
}
Expand
titleDel 4 - GuestManager (20%)

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.

Expand
titleLF

Observerbarhet handler om å la et eller flere objekter (observatørene/lytterne) få beskjed om endringer i et annet objekt (den observerte). Observert-klassen må administrere et sett med lyttere (objekter som implementerer et lyttergrensesnitt), vha. felt for Collection av lyttere og add/remove-metoder. Alle steder hvor tilstanden (til egenskapen) endres, må det skytes inn kode som sier fra til lytterne (kall på fire-metode, som går gjennom lytterne).

 

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).

Expand
titleLF
Capacity-egenskapen beregnes på bakgrunn av tables- og seatings-listene, og derfor må lytterne varsles hver gang disse endres (av addTable, removeTable, addSeating og removeSeating). Det skilles ikke mellom om kapasiteten øker eller minker, selv om det er økning som GuestManager er interessert i. Lyttere registreres med add/removeCapacityListener-metoder og en fireCapacityChanged-metode, som varsler lytterne (CapacityListener-implementasjoner), kalles av endringsmetodene.
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.

Expand
titleLF

GuestManager må ha en liste Group-objekter som fungerer som en kø. Ved ankomst med groupArrived, så prøves først å kalle addSeating. Hvis det ikke går, så legges Group-objektet i køen. Når gruppa drar, så brukes removeSeating. For å kunne tømme køen, må det lyttes på endringer i kapasiteten, altså må GuestManager implementere CapacityListener og legge seg til som lytter på Diner-objektet. I capacityChanged-metoden må en gå gjennom køen og igjen prøve addSeating og evt. fjerne Group-objektet fra køen, hvis det gikk greit.

 

Eksempelkode:

Code Block
public class GuestManager implements CapacityListener {
 
       private final Diner diner;
      
       public GuestManager(Diner diner) {
              this.diner = diner;
              diner.addCapacityListener(this);
       }
      
       private Collection<Group> waitingGroups = new ArrayList<>();
 
       public void groupArrived(Group group) {
              if (! diner.addSeating(group)) {
                      waitingGroups.add(group);
              }
       }
 
       public void groupDeparted(int tableNum) {
              diner.removeSeating(tableNum);
       }
 
       @Override
       public void capacityChanged(Diner diner) {
              Collection<Group> q = new ArrayList<Group>(waitingGroups);
              waitingGroups.clear();
              Iterator<Group> it = q.iterator();
              while (it.hasNext()) {
                      Group waiting = it.next();
                      if (diner.addSeating(waiting)) {
                             it.remove();
                      }
              }
              waitingGroups.addAll(q);
       }
}
Expand
titleDel 5 - Diverse (10%)
Oppgave a)

Er CapacityListener et funksjonelt grensesnitt? Begrunn svaret!

Expand
titleLF

CapacityListener-grensesnitt er (teknisk sett) funksjonelt, siden det bare har én (abstrakt) metode (og kan derfor implementeres med lambda-syntaksen). Dette kreves i et svar som får poeng i det hele tatt. I tillegg bør andre argumenter (for at grensesnittet ikke er funksjonelt) trekkes inn, f.eks. at metoden typisk ikke er implementasjonens primære funksjon og at en ikke tenker på den som en matematisk funksjon som kun er avhengig av argumentene.

 

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!).

Expand
titleLF
Code Block
public boolean isOccupied(Table table) {
       return seatings.stream().anyMatch(s -> s.getTable() == table);
}
 
public int getCapacity(boolean includeOccupied) {
       Stream<Table> stream = tables.stream();
       if (! includeOccupied) {
              stream = stream.filter(t -> ! isOccupied(t));
       }
       return stream.mapToInt(Table::getCapacity).sum();
}
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.

Expand
titleLF
Man må rigge opp en Diner med minst to bord og én Seating, og så sjekke at isOccupied returnerer riktig verdi for hvert bord. En kan også fjerne en Seating og sjekke isOccupied etterpå. Opprigging er enklere og testen mer spisset om en får mulighet til å legge inn (og fjerne) Seating-objekter uten å måtte bruke addSeating(Group) (evt. removeSeating(tableNum), så derfor kan en legge til en pakke-privat addSeating(Seating)-metode (evt. removeSeating(Seating)) i Diner
Expand
titleDel 5 - (10%)
Oppgave a)

Expand
titleLF

 

Oppgave b)

.

Expand
titleLF
.
Oppgave c)

.

Expand
titleLF
.
Expand
titleAppendix 1
Code Block
/**
 * This class ...
 */

...