Utilizzo di ObserverPattern, ma è necessario interrompere alcuni osservatori che mostrano immediatamente le modifiche

Question

Utilizzo di ObserverPattern, ma è necessario interrompere alcuni osservatori che mostrano immediatamente le modifiche

#1 da (4 voti)
#2 da (1 voti)
#3 da (0 voti)
#4 da (0 voti)

4

In un'applicazione GUI (per organizzare le immagini), utilizzo il Pattern osservatore (o qualcosa di simile al controller vista modello (vista)) per informare gli altri componenti sulle modifiche.

Assumendo tre componenti A, B, C che mostrano aspetti diversi di alcuni oggetti, posso attivare "azioni batch" che influenzano molti oggetti in A e B. Ogni cambiamento porterà ad un aggiornamento dell'insieme di oggetti in qualsiasi o tutti A, B, C, a seconda del cambiamento.

Se A fa scattare un cambiamento di tre oggetti, B e C mostreranno tre cambiamenti successivi ciascuno. Oltre a prendere tempo, è tremolante l'interfaccia utente.

Ciò di cui ho bisogno è un modo globale (argh!) che dice che durante l'azione batch, non dovrebbero verificarsi modifiche all'interfaccia utente. Dal momento che non vorrei limitare l'utilizzo di ObserverPattern alle cose dell'interfaccia utente, non vorrei interrompere l'intero pattern, ma solo la parte relativa all'interfaccia utente.

Qualche idea? Quando mi sono imbattuto in questa situazione, stavo pensando che fosse un requisito normale e mi sono chiesto perché non avevo mai trovato una soluzione.

gui observer-pattern

posta virtualnobi 10.10.2016 - 11:16

fonte

4 risposte

Leggi altre domande sui tag gui observer-pattern

Sicurezza gateway API (per architettura microservizi) Devo / posso raggruppare node.js e mongodb insieme alla mia applicazione?

score 4 · Answer 1

Potresti essere interessato a utilizzare qualcosa come Reactive Extensions per eseguire elaborazioni di eventi più complesse.

In particolare, l'uso del filtro di esempio potrebbe essere solo quello che vuoi qui.

Se unisci tutti gli eventi che generano un aggiornamento dell'interfaccia utente in un singolo flusso e campione in tale flusso, puoi evitare inutili aggiornamenti dell'interfaccia utente.

score 1 · Answer 2

Ci sono alcune strategie che prenderei in considerazione:

Aggiorna su un intervallo.
Scegli un intervallo in base al più lungo che desideri aspettare per vedere un aggiornamento e il tempo più lungo potresti essere in attesa tra le notifiche. Accodare le notifiche e gestirle e l'aggiornamento dell'interfaccia utente in un intervallo o, più semplicemente, gestire le notifiche non appena arrivano e aggiornare semplicemente l'interfaccia utente in un intervallo.
Supera% oggettibatch tramite le notifiche.
Includi un elenco di oggetti che fanno parte del batch, uno ObjectsCount o uno stato BatchCompleted . Qualunque sia la cosa più facile da includere e / o interpretare.
Aggiungi ogni modifica in Batch e guarda BatchJobs canale / oggetto.
La tua Batch può includere una raccolta di modifiche o oggetti modificati. Puoi ritardare l'inserimento nel canale fino al suo completamento oppure includere uno stato di IsComplete e renderlo osservabile (o includere solo un evento OnComplete ).

score 0 · Answer 3

Dovresti introdurre un livello intermedio tra l'Osservato e gli Osservatori. Invece di avere Y Observe Z direttamente (Y < -Z), Y osserva X e osserva Z (Y < -X < -Z). Quando X viene informato dell'evento di Z, può ritardare la pubblicazione del proprio evento su Y finché non si è pronti.

score 0 · Answer 4

Ecco cosa ho finito per concludere: il mio PausableObserverPattern su Github. Commenti benvenuti!

Le estensioni reattive menzionate da @MetaFight sembravano troppo grandi (cioè troppo complesse) per me.

L'aggiornamento su un intervallo non funziona poiché non so per quanto tempo sarà necessario il processo batch.

Poiché utilizzo un ObserverPattern molto semplice (vedi github), non esiste un modo semplice per passare ulteriori dati sul batch di modifiche.

La risposta di @ user889742 ha attivato il mio pensiero: solo il livello "intermedio" che menziona è la classe Observable (in realtà una sottoclasse).