Il concatenamento di eventi è considerato una buona pratica?

Di tanto in tanto ho incontrato scenari in cui è necessario soddisfare diverse condizioni complesse prima di attivare un evento. Inoltre, la maggior parte degli ascoltatori esegue anche controlli aggiuntivi per determinare il corso dell'azione. Questo mi ha fatto pensare se una soluzione migliore sarebbe quella di pensare in termini di eventi più piccoli e lasciarli innescare l'uno nell'altro.

Concatenare eventi mi permetterebbe di intrecciare altri ascoltatori in seguito con uno sforzo abbastanza basso (possibile violazione di YAGNI?). Il mio codice consisterebbe in semplici elementi facilmente comprensibili, che non dovrebbero essere difficili da comprendere per gli altri.

Tuttavia, i possibili svantaggi di questa soluzione sarebbero il fatto che se qualcosa dovesse andare storto nella catena (ad es. Innesco di eventi falsi a causa di un errore umano), sarebbe piuttosto difficile individuare il bug.

Il concatenamento di eventi è una buona idea ^TM ? In caso contrario, quali sono i metodi alternativi per mantenere ingombra il codice relativo agli eventi?

Il concatenamento di eventi è una buona idea?

È una di quelle cose che sembra davvero una buona idea, fino a quando non la usi.

È molto difficile impostare eventi a cascata senza una sorta di dipendenza implicita dall'ordine. È difficile configurarli senza causare problemi a causa di infiniti loop e occasionali perdite di memoria. Rendono più difficile la progettazione delle classi a causa dell'accoppiamento causato da eventi che necessitano di sapere sia dove collegarsi che dove collegarsi.

E sono molto difficili nel debug e nel ragionamento sul codice.

Ora a volte possono essere utilizzati in scenari relativamente limitati in cui la struttura del codice limita alcuni di questi problemi. Nelle UI, gli eventi a cascata possono essere utilizzati per attivare la gerarchia poiché tale struttura gerarchica aiuta a limitare i problemi di proprietà e loop.

Tuttavia, trovo molto più spesso in questi giorni che accetto un delegato in un costruttore per quel tipo di comportamento estensibile che lasciare che il comportamento arbitrario si agganci in fase di esecuzione.

Il concatenamento di eventi è una buona idea se

• È generalmente appropriato per il tuo scenario. Un semplice esempio è l'azione dell'interfaccia utente di un utente che attiva altri eventi visivi.
• Ogni evento è autonomo e gestibile. Non vuoi che la soluzione diventi eccessivamente ingombrante.
• Il flusso di controllo è facile da seguire. Deve essere implementato su una piattaforma e in una lingua che è facile per uno sviluppatore. Se hai bisogno di rintracciare metodi "magici" per rintracciare ciò che sta accadendo, stai seguendo la strada sbagliata.

È molto importante pensare alla soluzione e generalizzare alcune cose prima di iniziare a costruire il sistema. Ad esempio, in un linguaggio OO dovresti avere un'interfaccia di base o una classe astratta come base per tutti gli eventi. Quella classe dovrebbe incorporare cose come logging / debugging. È inoltre possibile che si desideri una classe di gestione degli eventi generalizzata per gestire in modo corretto gli errori.

Parlando dal punto di vista di qualcuno che una volta ha trascorso un paio di giorni a rintracciare un errore relativo alla catena di eventi, questa è una pessima idea (sm). Stai nascondendo il tuo flusso di controllo che (come hai notato) può rendere il debug un incubo. La situazione in cui mi trovavo sorse quando qualcuno aggiunse un codice di gestione degli errori che resettava un controllo. Ciò portò a una catena di onPropertyChangegestori che finì per rinfrescare il controllo che aveva il gestore degli errori, che lo portò a ripristinare di nuovo l'altro controllo e così via. Fondamentalmente l'interfaccia utente si bloccherebbe semplicemente con la CPU fissata al 100%.

Se hai un modo per impedire che i gestori di eventi vengano attivati ​​più di una volta per lo stesso evento di root, potresti essere in grado di evitarlo, ma posso immaginare situazioni in cui potresti desiderare più invocazioni di gestori di eventi.

L'implementazione del concatenamento di eventi è difficile, per tutti i motivi citati da altri.

Tuttavia, è anche la premessa di base della maggior parte dei motori delle regole. JBoss Drools, IBM jRules, PegaSystems, Corticon e FICO Blaze Advisor sono tutti i principali sistemi di gestione delle regole aziendali (BRMS) che consentono agli utenti di dichiarare regole che si attivano in base agli eventi che si verificano nei sistemi. Sia il concatenamento in avanti che all'indietro sono possibili e fattibili.

Il linguaggio Prolog e i suoi derivati ​​si basano sulla stessa nozione.

Gli algoritmi coinvolti non sono semplici, il debug PU be essere una seccatura, ma c'è molto valore nel modello.

Un potenziale svantaggio è che è abbastanza facile finire accidentalmente con aggiornamenti in loop. ad es. A -> B -> C -> A -> B ...

Un altro approccio è quello di creare eventi compositi responsabili dell'incendio di una sequenza di eventi. Ciò significa che non dovresti finire bloccato in un ciclo e ti dà un unico posto per catturare errori / ecc. Ho avuto un certo successo con questo, anche se è vero che non l'ho mai usato per qualcosa di particolarmente complicato (ancora!).