C # Subject Observer Architecture question

1

Sto creando un'applicazione C # usando il modello di progettazione Soggetto osservatore in un modo leggermente diverso.

Sto passando la classe Provider, implementando IObservable (questo ha il metodo OnNext () che notifica tutte le classi che lo sottoscrivono), al costruttore Observer Class, implementando IObserver (questo agisce sul metodo OnNext () inviato dal classe fornitore).

In questo modo ogni singola classe Observer ha la capacità di eseguire il metodo OnNext () anche notificando altre classi di modifiche.

Quindi un aspetto molto semplicistico del mio progetto di esempio è simile a:

ProviderClass provider;
ObserverClass observer1;
ObserverClass observer2;
.......... observer3;
.......... observer'n';

main()
{
    provider = new ProviderClass();
    observer1 = new ObserverClass(provider);
    observer2 = new ObserverClass(provider);
    observer3 = new ObserverClass(provider);
    provider.subscribe(observer1);
    provider.subscribe(observer2);
    provider.subscribe(observer3);
    ............
    ............
    // arbitrary code happens here
    ............
    ............
    // later in code observer1,2,3 can each post OnNext() methods 
    // that each other observer class will also catch since they all have
    //, so with some
    // filtering of objects being passed in each OnNext() method 
    // I think this is a great way of passing data from one class to
    // another.
}

class ObserverClass : IObserver<Object>
{
    ProviderClass copyInstance;

    // Now the observer class can notify other classes using OnNext()
    public ObserverClass(Provider copy)
    {
        copyInstance = copy;
    }

    public virtual Override OnNext(....)
    {
        // perform specific action
    }

    public void notifyClasses(...)
    {
       copyInstance.OnNext(...);
    }
}

Esistono alcuni svantaggi nella modifica del modello di progettazione di Subject Observer in questo modo?

    
posta CD VA Programmer 28.03.2015 - 00:54
fonte

3 risposte

1

Sembra che tu stia usando l'osservatore come un editore e un abbonato, mentre il Provider è solo un editore. O è anche entrambi? Questo sembra un po 'confuso.

Forse dovresti creare un tipo di Bus o di Coda che puoi sia pubblicare che sottoscrivere. Ci sono così tante complessità nella messaggistica che dovresti davvero rendere responsabile un componente distinto per gestirlo solo.

    
risposta data 28.03.2015 - 20:57
fonte
0

Are there any drawbacks to modifying the Subject Observer design pattern this way?

Bene, sì.

  • Quello che vedo è all'indietro, dentro e fuori; un'implementazione errata

    • L'osservatore ( ObserverClass ) non dovrebbe essere il notificatore - il notificatore è il tuo ProviderClass . Il notificatore avvisa, osserva l'osservatore.
    • Avere il ObserverClass che chiama i metodi dei provider non ha senso.
    • Il codice sta configurando un riferimento circolare, apparentemente. Il provider chiama l'osservatore che a sua volta chiama il metodo del provider, che a sua volta ...
  • Se vuoi osservare "a catena", una classe può implementare sia IObservable che IObserver .

Are there any drawbacks to modifying the Subject Observer design pattern this way?

Bene, sì.

  • Quello che vedo è all'indietro, dentro e fuori; un'implementazione errata

    • L'osservatore ( ObserverClass ) non dovrebbe essere il notificatore - il notificatore è il tuo ProviderClass . Il notificatore avvisa, osserva l'osservatore.
    • Avere il ObserverClass che chiama i metodi dei provider non ha senso.
    • Il codice sta configurando un riferimento circolare, apparentemente. Il provider chiama l'osservatore che a sua volta chiama il metodo del provider, che a sua volta ...
  • Se vuoi osservare "a catena", una classe può implementare sia IObservable che IObserver .

RE: 4/8/2015 commento

one class reads in files and searches for a keyword

Sento un singolo problema di principio di responsabilità. In genere vedo la funzionalità I / O come una "singola responsabilità". Dove mettere la ricerca dipende dal design generale.

the second class handles emailing the owner of the program ... [of the found keyword].

Suona bene. Prenderò in considerazione che la ricerca di una parola chiave è l'evento innescato.

If both classes were instantiated in the main c# class then ...

Hai un buon posto per coordinare le attività. La bontà OO qui è che l'Observer e l'Observable non devono conoscersi l'un l'altro. I tipi di classe e le firme dei delegati degli eventi garantiranno che possano lavorare insieme.

Quindi "la classe C # principale":

  1. Registra un gestore di eventi IObserver dell'oggetto per suo conto su IObservable .
  2. Sospetto che possa prendere questi oggetti come parametri costruttore / metodo.

  3. Chiama la classe I / O per scaricare il file.

  4. Passa il file al metodo / classe che cerca - questo è IObservable , se indovino giusto sull'intento.

  5. Qualunque sia la ricerca attiva l'evento quando viene trovata la parola chiave.

  6. Può annullare la registrazione anche del gestore di eventi. Dipende dal ciclo di vita dell'oggetto, dalla progettazione, dall'intento, ecc.

Fine RE: 4/8/2015 commento

    
risposta data 28.03.2015 - 04:28
fonte
0

Sono abbastanza d'accordo con ciò che dice la risposta @radarbob. Per qualche tempo mi sono chiesto anche come implementare un tale modello di design nella "vita reale". Va bene leggendo su di esso per capire il modello di progettazione teoricamente, ma effettivamente applicarlo è diverso.

Se hai accesso a Pluralsight ti consiglio vivamente il seguente video (vale la pena iscriversi con una versione di prova per):

Modelli di progettazione tattica in .NET

Penso che i problemi che affronta e gli argomenti di cui parla (in particolare riguardo al modello di osservatore), potrebbero avvantaggiarti.

    
risposta data 09.04.2015 - 21:18
fonte