Il modello di osservatore è adatto quando gli osservatori non sono indipendenti l'uno dall'altro?

Ho finito per andare con l'opzione 3 - utilizzando un gestore esterno. Il gestore è responsabile dell'aggiunta e rimozione di State s da Car s e della notifica agli osservatori quando queste modifiche si verificano.

Ecco come ho modificato il codice. Ho rimosso Observable / Observer di JDK perché sto facendo la mia implementazione.

Ogni State mantiene un riferimento al Car a cui è stato applicato.

abstract class State {

    Car car;

    State(Card car) { this.car = car; }

    public abstract void update();
}

class Upgrade extends State {

    @Override
    public void update() {

        int bonus = car.states.size() - car.states.indexOf(this) - 1;
        car.price += bonus;
        System.out.println(car.inStock + " " + car.price);
    }
}

class Shipping extends State {

    @Override
    public void update() {

        car.inStock = false;
        System.out.println(car.inStock + " " + car.price);
    }
}

Car mantiene solo il suo stato (per evitare confusione: proprietà) e non gestisce l'aggiunta e la rimozione di State s:

class Car extends Observable {

    List<State> states = new ArrayList<>();
    int price = 100;
    boolean inStock = true;
}

Ecco il manager. Ha superato il Car s (il lavoro osservabile) di gestirne il State s (osservatori).

class StatesManager {

    public void addState(Card car, State state) {

        car.states.add(state);
        for (State state : car. states)
            state.update;
    }

    public void removeState(Card car, State state) {

        car.states.remove(state);
        for (State state : car. states)
            state.update;
    }
}

Alcune cose da tenere a mente:

• Tutti gli osservatori vengono avvisati di ogni cambiamento. Uno schema di distribuzione degli eventi più intelligente può eliminare le chiamate non necessarie al metodo update degli osservatori.
• Gli osservatori potrebbero voler esporre più metodi di "aggiornamento" per le diverse occasioni. Ad esempio, possono dividere il metodo attuale update in updateOnAdd e updateOnRemove se sono interessati solo a una di queste modifiche. Quindi i metodi addState e removeState verrebbero aggiornati di conseguenza. Insieme al punto precedente questo approccio può diventare un meccanismo robusto, estensibile e flessibile.
• Non ho specificato cosa fornisce l'istruzione per aggiungere e rimuovere State s e quando ciò accade non è importante per la domanda. Tuttavia, nel caso di questa risposta, c'è il seguente punto da considerare. Poiché State ora deve essere creato con il suo Car (nessun costruttore vuoto esposto) prima di chiamare il metodo del gestore, i metodi addState e removeState non devono prendere un Car e possono semplicemente leggerlo da state.car .
• Gli osservatori vengono avvisati in ordine di registrazione sull'osservabile di default. È possibile specificare un altro ordine.

Gli osservatori lavorerebbero alla grande se si calcolasse il sistema in modo diverso. Invece di rendere gli stati essi stessi degli osservatori, potresti fare in modo che 2 nuove classi siano "osservatori del cambiamento di stato": un osservatore aggiorna il "prezzo", un altro aggiornerebbe "inStock". In questo modo sarebbero indipendenti se non si hanno regole per il prezzo a seconda di inStock o viceversa, cioè se tutto potrebbe essere calcolato guardando solo i cambiamenti di stato. Questa tecnica è chiamata "event sourcing" (ad esempio vedi - link ). È un modello in programmazione che ha alcune applicazioni degne di nota.

Rispondendo a una domanda più generale, a volte hai davvero delle dipendenze tra gli osservatori. Ad esempio, potresti volere che un osservatore reagisca prima di un altro. In tal caso, in genere è possibile eseguire un'implementazione personalizzata della classe Observable per gestire ordini o dipendenze.