Come semplificare la struttura di un software di monitoraggio che utilizza il pattern Observer?

È un buon istinto da ostacolare nella creazione di cento classi molto simili. Questo è generalmente un segno che dovrebbero essere istanze . Potresti provare qualcosa come:

monitors.createIntMonitor("Floor", "DM141")
monitors.createBoolMonitor("Front door open", "DM142")
monitors.createEnumMonitor("Direction", "DM140", ["Up", "Down", "None"])
// or alternately
monitors.createEnumMonitor<ElevatorDirection>("Direction", "DM140")

monitors.getMonitor("Front door open").addObserver(observer)

Questo design può essere facilmente inizializzato dinamicamente, ad esempio da un file di configurazione o database, inclusa l'aggiunta di nuovi campi, senza richiedere la ricompilazione dell'app. Questi tipi di cambiamenti spesso finiscono per essere il più grande costo di manutenzione se lo fai staticamente. Richiede anche molte meno modifiche di copia / incolla / minori, che sono una grande fonte di errori.

Lo svantaggio è che non ricevi più errori di compilazione quando metti un RearDoorMonitor in una variabile che si aspetta un FrontDoorMonitor . È anche un po 'più problematico raggruppare più osservatori in una classe, ma in genere non è comunque la soluzione migliore.

I tuoi abbonati per un monitor enum templato potrebbero avere questo aspetto:

// Common interface
template <typename T>
class Subscriber
{
    public:
      virtual void receiveEvent(T t) = 0;
};

// Individual subscriber instance
class ElevatorSubscriber : public Subscriber<ElevatorDirection>
{
    public:
        void receiveEvent (ElevatorDirection direction);
};

Stai cercando Boost.Signals2. In questo caso, ogni "monitor" è solo un'istanza di boost::signals2::signal<void(ElevatorDirection)> , ad esempio. E ogni "osservatore" è solo una funzione casuale della firma appropriata, come una lambda. Puoi semplicemente chiamare il segnale ogni volta che ti serve e aggiungere / rimuovere i metodi forniti. Nessuna cazzata richiesta.

Il modello di Osservatore non è affatto un modello. È solo una classe. Una classe che non devi nemmeno implementare.

Vorrei provare a trovare una via di mezzo. Se ci sono, come hai scritto, un centinaio di tipi di informazioni, la possibilità è alta ci saranno molti tipi simili, con firme di interfaccia simili. Ad esempio, invece di avere ElevatorFrontDoorStatusMonitor e ElevatorRearDoorStatusMonitor , crea ElevatorDoorStatusMonitor , dove "Front" o "Rear" è solo un parametro. Se sono presenti sensori per ogni piano, impostare il numero del piano come parametro.

Potresti finire con una dozzina di diversi tipi di osservatori, forse più, forse meno, ognuno dei quali supporta una diversa lista di "tag pic". Quali dei tag pic che puoi raggruppare dipende, ovviamente, da quanto differiscono le operazioni nel tuo programma per i diversi tipi.