Design pattern per modificare lo stato e notificare gli altri modificatori senza un loop

Question

Design pattern per modificare lo stato e notificare gli altri modificatori senza un loop

#1 da (6 voti)

0

L'idea è che ho un set di proprietà che rappresentano le possibili opzioni nell'app. Queste opzioni possono essere modificate in vari modi, ad esempio dall'interfaccia utente, da remoto, da terze parti, ecc ...

Ogni volta che uno di questi modificatori modifica lo stato, gli altri modificatori devono essere avvisati. Ad esempio: se l'utente contrassegna una casella di controllo nell'interfaccia utente, il modificatore remoto e la terza parte devono essere avvisati, in modo che aggiornino il loro stato interno.

Non è prevista alcuna priorità e le modifiche allo stato non possono essere rifiutate. L'unica preoccupazione è di impedire a terzi di ricevere una notifica quando modifica lo stato stesso.

Esiste un buon modello di progettazione per risolvere questi requisiti?

design-patterns object-oriented-design pubsub

posta NullOrEmpty 12.09.2014 - 12:36

fonte

1 risposta

Leggi altre domande sui tag design-patterns object-oriented-design pubsub

Unit Test di grandi azioni del controllore Qual è il modo più robusto ed estensibile per rappresentare un contratto nel codice? [chiuso]

score 6 · Accepted Answer

La domanda è un po 'vaga (ad esempio cosa intendi esattamente per una terza parte?), ma per provare comunque a rispondere:

Penso che tu stia cercando il pattern Observer. L'intento del modello è quello di consentire alle entità di essere avvisate quando lo stato di alcuni oggetti cambia, mentre disaccoppia le due parti. Ad esempio, gli osservatori non sanno nulla del soggetto, tranne che è osservabile, e il soggetto non sa nulla degli osservatori, tranne che possono essere avvisati.

Puoi registrare tutti i modificatori come osservatori nella tua app (qualsiasi parte di essa abbia più senso e sia pertinente alla tua situazione: la GUI, la facciata del modello se ne hai uno, ecc ...), e poi tu può inviare loro una notifica ogni volta che lo stato dell'app cambia, pur mantenendo tutti disaccoppiati e mantenendo le cose flessibili.

Modifica: se si utilizza il pattern MVC, la classe Model (più precisamente la classe facade del sistema backend) è probabilmente il soggetto che gli osservatori ascolteranno, poiché memorizza lo stato dell'app e può notifica agli osservatori quando qualcosa cambia.