Quali sono i sintomi in un codebase che indicano che è necessario un approccio listener-evento?
Mi sembra che quando ci sono classi che devono essere chiamate da più, non definite in una serie di altre classi, è necessario un qualche tipo di quadro di segnalazione, ma mi piacerebbe sentire quali altre situazioni ci sono che sarebbe migliorato passando a un modello basato su eventi.
L'avvio di Event / Listener cerca di evitare accoppiamento stretto , quindi tutti gli odori di codice che indicano che, punterebbero all'appoach.
In base a ciò, vorrei suggerire i seguenti sintomi:
grandi costruttori , poiché ogni oggetto ha bisogno di conoscere ogni altro oggetto e non può funzionare senza. Magari travestito da molti% co_de immediatamente dopo la chiamata del costruttore.
dipendenze bidirezionali , perché, senza eventi, in un linguaggio imperativo, il flusso di informazioni è fondamentalmente 'push' (chiamata metodo someones)
"gerarchia della conoscenza" è difficile da determinare . Questa è la dipendenza bidirezionale , un altro punto focale: se c'è A, che ascolta B, A conosce B, ma B non di A, quindi c'è una 'gerarchia': alcuni oggetti don ' so qualcosa, alcuni ne conoscono altri, ecc. Ad esempio, quando si implementa MVC in questo modo: link , il modello conosce solo se stesso , la vista conosce il modello e il controller conosce la vista e il modello.
Quando non puoi o non devi sapere cosa dovrebbe reagire a una serie di messaggi / segnali / eventi.
Spesso è quando vuoi che "il mondo" sappia qualcosa in un modulo (una classe o un sistema di classi) ma non vuoi preoccuparti di ciò che viene chiamato.
L'odore del codice associato, per essere precisi, è quando senti che inizi a mischiare il codice da moduli indipendenti, facendo qualcosa a cui l'altro dovrebbe reagire. Una volta che vedi che devi chiamare il codice dal modulo B a seconda dello stato / degli eventi del modulo A, hai bisogno di ascoltatori di eventi.
Vorrei cambiare la tua domanda e dire: quando un evento basato non è la soluzione giusta per un'applicazione orientata agli oggetti? Penso che la maggior parte delle applicazioni OO possa beneficiare se sono progettate come produttori di eventi e consumatori.
Alla fine, una "chiamata di metodo" è in realtà un messaggio che arriva a un oggetto e l'oggetto è responsabile per decidere se sta andando a fare qualcosa con il messaggio ed eseguire l'operazione. Questo non è molto chiaro in linguaggi strongmente tipizzati come Java, ma diventa più ovvio in linguaggi dinamici come Ruby.
Un altro aspetto interessante della progettazione di un'applicazione basata su eventi è che di solito i componenti interni devono essere correttamente isolati e coerenti, altrimenti il codice diventa un disastro molto, molto rapidamente. Ad esempio, mi piace molto il concetto di Hexagonal Architecture usato da Alistair Cockburn, come di solito questo modello crea un incapsulamento migliore e forze (a mio avviso) più componenti coesive.
Penso (ma probabilmente ho torto) che questo è anche legato al concetto di Domain Driven Design di Domain Events , in cui le classi di dominio emettono eventi catturati da altri oggetti, e questi oggetti emettono ancora altri eventi (vedi dove sta andando: D). Quello che mi piace di questo modello è che dice che le interfacce dovrebbero modellare i ruoli, non le implementazioni.
Scusa se non ho molto senso, ho sperimentato questi pattern negli ultimi mesi con risultati sorprendenti, ma sto ancora cercando di capire i concetti e la loro portata.
Pensa a cosa dovresti fare se i listener di eventi (ovvero il Pattern di Osservatore) non esistessero.
Se hai un oggetto che ha riferimenti a un elenco di altri oggetti e chiama un metodo su di essi in un dato punto del processo, dovresti avere sicuramente un evento lì.
Se hai un flag su un oggetto per dire che qualcosa è stato fatto e stai guardando quel flag da altri oggetti, dovresti sicuramente aver usato un modello basato su eventi.
Tuttavia, non confondere questo con un callback. Se chiami un metodo su un altro oggetto e lo passi ad un metodo sull'oggetto di origine per richiamarlo in un dato momento, dovresti lasciarlo in quel modo, piuttosto che usare un listener di eventi.
Leggi altre domande sui tag architecture design-patterns code-smell