Nel razionalizzare ciò, suggerirei che dobbiamo prima riconoscere che nei sistemi del mondo reale, un accoppiamento è del tutto normale. Anche se in genere si desidera mantenere questo livello su un livello di astrazione più elevato ed evitare l'accoppiamento durante l'implementazione.
Ad esempio, potresti avere un database nel tuo sistema. Non sarai in grado di rimuovere l'accoppiamento del database da tutte le parti del resto del sistema, alcuni altri componenti dovranno essere a conoscenza del fatto che hai un database, perché avranno interagire con esso è in qualche modo, implicitamente o esplicitamente. I tuoi componenti astratti nel tuo sistema non possono semplicemente vivere in totale isolamento.
Potresti avere stakeholder che trarrebbero vantaggio dalla possibilità di cambiare facilmente l'implementazione del database, come passare da MSSQL a MySql, quindi dovrai assicurarti di astrarre il database correttamente e mantenere nascosti i suoi dettagli di implementazione in modo che il sistema non è accoppiato a un motore di database specifico. Al contrario, a volte la scelta migliore può essere quella di scegliere un particolare motore di database e esporlo completamente nel sistema, come se si presentassero requisiti di prestazioni che sovrappesano i requisiti di modularità.
L'accoppiamento è normale e dovremmo ragionare su dove metterlo nel sistema, non solo su come evitarlo.
E quando abbiamo un accoppiamento, dovremmo metterlo dove appartiene contestualmente senza cercare di indirizzare via.
Hai un componente di visualizzazione che attiva qualcosa come UserWantsToSeeDetailsForObject(id) ? È qualcosa che si può facilmente vedere appartenere contestualmente all'astrazione dell'applicazione stessa, quindi lo inserisco in qualcosa come una classe "ApplicationEvents". È logico che molti componenti diversi nella tua applicazione possano attivarlo.
Hai un componente come NetworkAnalyzer che controlla la connettività di rete e attiva eventi come "Riconnesso", "Disconnesso", "Instabile" e così via? Quegli tipi di eventi non avrebbero senso innescare da qualche parte al di fuori di NetworkAnalyzer , quindi basta evitare un po 'di indirezione e posizionarlo dove appartiene: all'interno di questo stesso componente.
Hai quindi bisogno di implementare diverse implementazioni di NetworkAnalyzer ? Inserisci la definizione dell'evento nella classe base.
Scoprirai quindi che il tuo sistema non deve solo essere consapevole della connettività di rete, ma anche di cose come la memoria disponibile, le risorse della CPU e la temperatura? Quindi ti renderai conto che hai un nuovo contesto astrattivo che potresti nominare qualcosa come "EnvironmentTelemetry", dove ha senso raccogliere quelle definizioni di eventi.
TL; DR
L'evento ha un chiaro proprietario? Basta metterlo con il proprietario ed evitare l'indecisione non necessaria.
L'evento ha senso nell'applicazione senza quale componente che hai appena scritto? Probabilmente appartiene all'applicazione nel suo insieme, quindi posizionalo in un costrutto strutturale condiviso (ad esempio una classe ApplicationEvents).
Il tuo evento specifico appartiene contestualmente ad un certo gruppo di altri eventi, non a livello di applicazione ma al di sopra di un singolo componente? Prendi in considerazione la creazione di una classe contenente quegli eventi specifici.