Problemet observatør-observert løser

Et objekt (den observerte) endrer tilstand, og andre objekter (observatørene/lytterne) må få vite det. Den naive løsningen er at det observerte objektet kjenner de konkrete klassene som skal varsles — men da må det endres hver gang en ny type lytter dukker opp. Løsningen er et lyttergrensesnitt: den observerte kjenner bare grensesnittet, og hvem som helst kan implementere det. Dette er det tyngst vektede enkelttemaet på nyere eksamener (15–20 % i 2019, 2020, 2020k, 2021 og 2021k).

Oppskriften

Fire deler, i denne rekkefølgen:

Lyttergrensesnittet med én callback-metode. Metoden tar med kilden og gjerne både gammel og ny verdi, slik at lytteren slipper å spøre tilbake.
Felt for lytterne i den observerte klassen, typisk Collection<X>.
addLytter/fjernLytter.
En privat fyrAv-metode som går gjennom lytterne og kaller callbacken — og som kalles fra alle metodene som endrer tilstanden.

public interface TemperaturLytter {
    void temperaturEndret(Termostat kilde, double gammel, double ny);
}

public class Termostat {
    private double temperatur;
    private final Collection<TemperaturLytter> lyttere = new ArrayList<>();

    public double getTemperatur() {
        return temperatur;
    }

    public void setTemperatur(double ny) {
        if (ny < -50 || ny > 50) {
            throw new IllegalArgumentException("Temperatur utenfor gyldig omraade");
        }
        double gammel = this.temperatur;
        this.temperatur = ny;
        if (gammel != ny) {              // varsle BARE ved faktisk endring
            fyrAvTemperaturEndret(gammel, ny);
        }
    }

    public void addLytter(TemperaturLytter lytter) {
        if (lytter != null && !lyttere.contains(lytter)) {
            lyttere.add(lytter);
        }
    }

    public void fjernLytter(TemperaturLytter lytter) {
        lyttere.remove(lytter);
    }

    private void fyrAvTemperaturEndret(double gammel, double ny) {
        for (TemperaturLytter lytter : new ArrayList<>(lyttere)) {   // kopi!
            lytter.temperaturEndret(this, gammel, ny);
        }
    }
}

De fire detaljene sensor ser etter

Varsle bare ved faktisk endring. Sammenlign gammel og ny verdi før du fyrer av. Sett den nye verdien i feltet før varslingen, slik at en lytter som kaller getTemperatur() får den nye verdien.
Kall fyrAv fra alle endringsmetoder — ikke bare fra den åpenbare setteren. Hvis klassen også har oekMed(double) eller nullstill(), må de enten kalle setteren eller fyre av selv.
Iterer over en kopi, eller bruk CopyOnWriteArrayList. Hvis en lytter melder seg av inne i callbacken, endres lista mens vi itererer over den, og du får ConcurrentModificationException.
Hold fyrAv privat. Ingen utenfra skal kunne påstå at noe er endret.

Når lytteren bare bryr seg om én verdi

En variant som har kommet flere ganger: lytteren registrerer seg for en bestemt tilstand, og skal varsles både når tilstanden nås og når den forlates. Da holder det ikke med en liste — du trenger en Map fra lytter til den verdien den er interessert i. En ny registrering av samme lytter skal overskrive den gamle, og det får du gratis med Map.put.

private final Map<NivaaLytter, String> lyttere = new HashMap<>();

public void addLytter(NivaaLytter lytter, String nivaa) {
    if (!GYLDIGE_NIVAA.contains(nivaa)) {
        throw new IllegalArgumentException("Ugyldig niva: " + nivaa);
    }
    lyttere.put(lytter, nivaa);          // put overskriver tidligere registrering
}

private void fyrAvNivaaEndret(String gammelt, String nytt) {
    for (Map.Entry<NivaaLytter, String> post : new HashMap<>(lyttere).entrySet()) {
        String interessant = post.getValue();
        if (interessant.equals(gammelt) || interessant.equals(nytt)) {
            post.getKey().nivaaEndret(navn, gammelt, nytt);
        }
    }
}

Lyttersiden

Lytteren implementerer grensesnittet og lagrer det den trenger. Et typisk eksempel er en rabattordning som gir 100 kroner i rabatt til alle som har nivået «Gull»:

public class Rabattordning implements NivaaLytter {
    private final Map<String, Integer> rabatter = new HashMap<>();

    @Override
    public void nivaaEndret(String brukernavn, String gammelt, String nytt) {
        if ("Gull".equals(nytt)) {
            rabatter.put(brukernavn, 100);
        } else {
            rabatter.remove(brukernavn);      // mistet gullnivaaet
        }
    }

    public int getRabatt(String brukernavn) {
        return rabatter.getOrDefault(brukernavn, 0);
    }
}

Observatør kontra delegering

Begge bruker et grensesnitt og et felt, men retningen er motsatt. Ved delegering ber objektet noen andre om å gjøre jobben og venter på svar; det er ett svar og én delegat. Ved observatør forteller objektet at noe har skjedd, uten å forvente svar; det kan være null, én eller mange lyttere, og de kan komme og gå. Spørsmålet «hva innebærer observerbarhet?» besvares presist slik: en egenskap er observerbar når andre objekter kan registrere seg for å bli varslet om endringer i den, uten at klassen som eier egenskapen kjenner dem.

Kobling mot JavaFX

På eksamen ender observatørdelen ofte i et JavaFX-panel: kontrollerklassen implementerer lyttergrensesnittet, registrerer seg på modellobjektet i initialize(), og oppdaterer en Label i callbacken. Da holder modellen seg helt fri for GUI-kode, og du kan teste den med JUnit ved å registrere en enkel testlytter som bare teller antall varsler.

Studieguide: Observatør-observert

Studieguide: Observatør-observert