Gli eventi imperativi sono un anti-modello?

Question

Gli eventi imperativi sono un anti-modello?

#1 da (6 voti)
#2 da (5 voti)
#3 da (1 voti)

3

Sono eventi che intendono dire agli ascoltatori di eseguire azioni esplicite come anti-pattern?

Immagina un servizio di lavoro che solleva l'evento WorkStarted all'inizio e l'evento WorkFinised alla fine.

Questi eventi trasmettono informazioni su ciò che il servizio per i lavoratori ha e non sono intrinsecamente imperativi per nessuno dei potenziali abbonati di quell'evento.

Considera che potrebbe essere l'intenzione dell'applicazione utilizzare questo evento per mostrare o nascondere un'icona di caricamento. È un anti-pattern per il servizio di lavoro per aumentare invece un ShowLoadingIcon e HideLoadingIcon evento?

In questo caso non è stata trasmessa alcuna informazione su ciò che il servizio di lavoro ha effettuato, ma viene fatta solo una richiesta istruttiva.

In quali casi, se ci sono, questi approcci sono inappropriati o preferiti?

EDIT: Per chiarire, sto chiedendo l'esistenza di standard per la programmazione basata sugli eventi. Tutte le domande di standardizzazione includono una certa quantità di opinioni, eppure il sito è disseminato di loro perché c'è una differenza tra una questione di preferenze personali e una di buone pratiche generalmente accettate.

event-programming pubsub

posta Matthew 04.06.2015 - 23:06

fonte

3 risposte

Leggi altre domande sui tag event-programming pubsub

IS C ++ un linguaggio multipiattaforma? [chiuso] Aiutando i tester che non hanno conoscenze di dominio specializzate

score 6 · Answer 1

Il modo in cui decidere cosa dovrebbe rappresentare un evento è il buon vecchio principio di responsabilità singola.

Se, ad esempio, si dispone di un processo di calcolo delle imposte di lunga durata e di una visualizzazione della GUI incrementale che mostra il suo avanzamento, il processore fiscale deve generare eventi "avviato", "progresso" o "fine". Una classe GUI dovrebbe ascoltare questi eventi e fare qualunque sia la GUI appropriata, ad es. mostra o nasconde l'icona "aspetta ...".

In questo modo, il tax processor elabora le tasse e la classe GUI esegue il rendering di una GUI. Se hai definito un evento "HideWaitIcon", il tax processor avrebbe dovuto conoscere i dettagli della GUI, che non è il suo lavoro (e che renderebbe più difficile scrivere un front-end diverso per lo stesso back-end). Ecco perché la nostra prima soluzione è superiore.

score 5 · Answer 2

Non sono affari tuoi ciò che intendo fare quando la tua API solleva un evento. Forse mostrerò un'icona, forse ordinerò il caffè allo sviluppatore principale, inizierò un video musicale, qualunque cosa faccia, sono affari miei e non tuoi. Il punto dell'evento è quello di informare coloro che sono interessati che qualcosa è successo, dopo di che, non è più il tuo concetto.

Come sviluppatore, è il tuo lavoro determinare quali eventi sono riportati utilmente - CompletedFirstStepOfSecondLoopInMethodA probabilmente non interessa a nessuno. Ma una volta stabilito che qualcosa deve essere segnalato, la tua parte è completa. Ciò che viene fatto dall'altra parte dell'evento non dipende da te.

score 1 · Answer 3

In ogni architettura basata sugli eventi che funziona bene, ci devono essere alcune regole che specificano alcuni ordini parziali (timeline) per gli eventi che si verificheranno in risposta ad alcune operazioni.

Esempio:

Ordine degli eventi in Windows Form

Se questi ordini vengono violati, anche solo per un pochino, il mondo guidato dagli eventi cade a pezzi. Questo dà origine a bug non deterministici o attivabili in modo esilarante, come "l'applicazione si arresta quando topo il mouse sulla barra dei menu quando l'applicazione sta facendo (qualcosa)".

Gli eventi provengono da una fonte e vengono inviati a uno o più listener.

Non è richiesto che il framework debba eseguire questo dispiegamento in modo strettamente deterministico e imperativo. In altre parole, sebbene il seguente sia un modello mentale molto popolare tra i programmatori, il framework non è necessariamente implementato in questo modo.

Nuovo evento: inserisce un nuovo messaggio in una coda.
Framework - per ogni messaggio che ha uno o più listener, distribuiscilo (replicalo) ai suoi ascoltatori.
Ogni ascoltatore attende un nuovo messaggio dalla coda.
Ogni listener acquisisce ed elabora il nuovo messaggio.

Si noti che i tipi di eventi potrebbero essere definiti in base all'origine (es. Work può avere eventi WorkStarted e WorkFinished ) o su azioni (affordances) che può eseguire (ad esempio ProgressIcon può ricevere ShowLoadingIcon , ShowFinishedIcon o ShowFailureIcon .)

In alcuni framework, gli eventi di origine e gli eventi di azione sono tipi separati e terminologie separate (in modo che questi ultimi non vengano definiti "eventi"). In alcuni altri framework sono entrambi chiamati eventi, a causa della la scelta del framework di implementare eventi usando un concetto unificatore chiamato delegati , che ha un modello mentale di un programmatore molto simile alle funzioni di callback.

Dovresti essere in grado di vedere da dove viene la tua confusione: perché il framework che stai usando rende tutte le chiamate di funzione come , hai l'illusione temporanea che tutto ciò che puoi fare con le chiamate di funzione, puoi anche farlo con i delegati, e per estensione anche fare qualsiasi cosa con gli eventi. Tuttavia, questa non è l'intenzione originale dell'architettura basata sugli eventi.

Inoltre, i programmatori che utilizzano framework diversi non affronteranno mai questa confusione e avranno difficoltà a capire perché questa domanda si pone.