C'è un equilibrio che deve essere raggiunto tra l'allentamento dell'accoppiamento e la complessità. In quanto responsabile per l'architettura generale, devi raggiungere questo equilibrio.
Quando chiamiamo un metodo ToString() su un oggetto, possiamo farlo in modo sicuro perché sappiamo che tutte le nostre classi derivano da una classe base che ha un metodo ToString() , e quel metodo può essere sovrascritto nelle classi derivate per ottenere risultati migliori. Aggiungiamo listener di eventi a ToString() ? No, non lo facciamo. Perchè no? Perché aggiungerebbe ulteriore complessità senza ulteriori vantaggi.
Aggiungiamo ascoltatori di eventi ad azioni che possono o meno avere un obiettivo corrispondente per ricevere l'azione? Ovviamente. Perché? Perché generalizza il nostro modello di classe e consente il passaggio facoltativo dei messaggi laddove appropriato.
Se hai due classi che lavoreranno sempre insieme, ma i cui metodi non parleranno mai con nessun'altra classe (almeno nell'ambito delle rispettive Interfacce), non li disaccoppieresti con gli eventi. Perché? Perché il disaccoppiamento non ha alcun senso in quel contesto. Il disaccoppiamento può effettivamente rendere le cose più difficili, perché ci sono situazioni in cui una classe deve avere conoscenza dello stato dell'altro per poter funzionare correttamente (in altre parole, devono coordinare i loro sforzi). Il disaccoppiamento fa sì che le classi sappiano meno l'una sull'altra, non di più.