Ha senso implementare un sistema di distribuzione degli eventi che consenta il bubbling degli eventi per gli oggetti non correlati alla GUI?

Certo che ha senso. Solo perché non puoi vedere qualcosa visivamente non significa che non possa utilizzare l'evento bubbling, men che meno gli eventi in generale.

Un esempio illustrativo:

Immagina di avere una sorta di modello ad albero, ad esempio un organigramma di una società e vuoi avvisare i superiori quando un nodo è inserito (nuovo dipendente) o qualcosa è cambiato. Potresti quindi, ad esempio, sollevare l'evento "Sviluppatore Jane appena sposata, il suo cognome cambiato in Smith". Alcuni dei più alti (come il suo capo reparto) potrebbero essere interessati a un tale evento e inviare un biglietto di auguri, aumentare il suo stipendio o semplicemente congratularmi con lei. Basta gonfiarlo, quindi i superiori non hanno bisogno di iscriversi all'evento di cambiamento di cognome di ogni persona in azienda, ma ottenerlo comunque e gestirlo, se lo desiderano.

La logica sarebbe molto più complicata quando dovevano sottoscrivere gli eventi di ogni individuo. Ogni volta che veniva aggiunto un individuo, dovevi attraversare l'albero per le persone interessate al nuovo individuo e iscriverti esplicitamente a qualsiasi evento di interesse. Dal punto di vista di un programmatore, questo è molto più complicato quindi semplicemente ricevendo l'evento e poi decidendo se ti interessa o meno. Porterebbe a una rete piuttosto complessa di interconnessioni che è più difficile da gestire e mantenere. La prima cosa che mi viene in mente sono possibili problemi di serializzazione.

Ora sono sicuro che ci sono esempi migliori là fuori, questo era solo il migliore che avrei potuto trovare in 30 secondi. Tuttavia, poiché intendi creare un sistema di distribuzione degli eventi, desidero indirizzarti al schema di aggregazione degli eventi , che è un ingegnoso strumento multifunzionale che un simile framework non dovrebbe mancare, migliore implementato come Microsoft lo fa secondo me.

Se stai costruendo il tuo sistema, sarebbe saggio studiare come il toolkit tk gestisce i collegamenti. Associa un elenco di tag (o bindtags) per il widget eAch. Quando un evento entra in un widget, la biblioteca ottiene l'elenco dei tag e cerca e applica ogni legame in ordine.

Di default l'ordine è più specifico (es .: il widget stesso) al meno specifico (es: la finestra più in alto). La bellezza del sistema è che puoi definire qualsiasi ordine tu desideri. Il 98% delle volte l'ordine predefinito è quello che desideri, ma a volte hai bisogno di qualcosa di diverso.

L'altra caratteristica di questo sistema è che ogni associazione può scegliere di avere o meno la bolla dell'evento. Se un gestore desidera il controllo completo, può gestire l'evento e quindi interrompere la catena. Oppure, può fare ciò che deve fare, quindi lasciare che gli altri handler abbiano il loro turno.

Non ho mai lavorato con un metodo di gestione degli eventi più potente, flessibile e semplice.

Oh, e non vi è alcuna limitazione che i tag debbano rappresentare oggetti visibili, o addirittura oggetti. Puoi avere tag che rappresentano le astrazioni (ad esempio, per impostazione predefinita ogni widget include il tag "all", il che significa che puoi associare a "tutti" e verrà attivato indipendentemente dal luogo in cui si verifica l'evento.