Il concatenamento degli eventi è considerato una buona pratica?

Is event chaining a good idea?

È una di quelle cose che sembrano davvero una buona idea, finché non la usi.

È molto difficile configurare eventi a cascata senza una sorta di dipendenza implicita dall'ordine. È difficile impostarli senza causare problemi dovuti a loop infiniti e perdite di memoria occasionali. Rendono più difficile la progettazione della classe a causa dell'accoppiamento causato da eventi che richiedono di sapere sia dove collegarsi sia dove eseguire la cascata.

E sono molto duri nel debugging 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 interfacce utente, gli eventi a cascata possono essere utilizzati per attivare la gerarchia verso il basso in quanto tale struttura gerarchica consente di limitare i problemi di proprietà e di looping.

Tuttavia, oggigiorno, trovo molto più spesso accettare un delegato in un costruttore per quel tipo di comportamento estensibile che lasciare il comportamento arbitrario in aggancio al runtime.

Il concatenamento degli eventi è una buona idea se

• In genere è 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 del controllo è facile da seguire. Deve essere implementato su una piattaforma e in un linguaggio che è facile da attraversare per uno sviluppatore. Se hai bisogno di rintracciare i metodi "magici" per rintracciare ciò che sta accadendo, stai seguendo il percorso sbagliato.

È 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 il logging / debugging. Potresti anche volere una classe di gestione eventi generalizzata per gestire i fallimenti con garbo.

Parlando dal punto di vista di qualcuno che una volta trascorse un paio di giorni rintracciando un errore relativo alla catena degli 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 è sorto quando qualcuno ha aggiunto un codice di gestione degli errori che ripristina un controllo. Ciò ha portato a una catena di onPropertyChange handler che si è conclusa aggiornando il controllo che aveva il gestore degli errori, il che ha portato a reimpostare nuovamente l'altro controllo, e così via. Fondamentalmente l'interfaccia utente si bloccherebbe semplicemente con la CPU ancorato al 100%.

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

Implementare eventi concatenando bene è difficile, per tutti i motivi menzionati da altri.

Tuttavia, è anche la premessa di base della maggior parte dei motori di 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 forwarding che il backward chaining sono possibili e fattibili.

Il linguaggio Prolog e i suoi derivati sono basati sulla stessa nozione.

Gli algoritmi coinvolti non sono semplici, il debugging può essere un dolore, ma c'è molto valore nel modello.

Un potenziale svantaggio è che è abbastanza facile finire accidentalmente con gli aggiornamenti di loop. per esempio. A - > B - > C - > A - > B ...

Un altro approccio consiste nel creare eventi composti che sono responsabili del fuoco di una sequenza di eventi. Ciò significa che non dovresti finire bloccato in un loop, e ti dà un posto unico per catturare errori / etc. Ho avuto qualche successo con questo, anche se devo ammettere che non l'ho usato per qualcosa di particolarmente complicato (ancora!).