C# Il modo migliore per comunicare tra le classi

Question

In questo momento sto codificando un'applicazione e sto pensando che ci sia una soluzione migliore per quello che sto facendo adesso.

Ho una finestra principale che deve gestire le impostazioni del programma. Poi ho altre classi e finestre. Ad esempio una classe di gestione della lingua e un modulo che gestisce l'input dell'utente necessario per la "funzione principale".

Tuttavia, fino ad ora devo sempre passare la mia finestra principale a ciascuna di queste classi, perché il gestore linguistico deve essere in grado di modificare le stringhe della finestra principale. E l'altra forma dovrebbe anche essere in grado di passare i dati alla finestra principale.

Se immaginiamo che ci saranno molte più classi e ogni classe ha bisogno di una copia della finestra principale, questo consumerebbe molte risorse a seconda della "dimensione" della finestra principale.

Quindi, c'è un modo migliore/più efficace per comunicare tra queste classi.

Answer 1

Il modo più semplice per farlo è utilizzare observer pattern, che in .NET è events system. Detto semplicemente, le tue classi si iscrivono agli eventi degli altri e svolgono un'azione quando viene sollevato un evento. Come notato nel commento, i riferimenti di passaggio non sono pesanti in memoria, ma si traducono in un accoppiamento stretto tra diversi pezzi del codice: il modello di osservatore risolve questo problema.

Answer 2

Ti suggerisco di utilizzare le implementazioni di MVVM Galasoft o Prism MVVM. Lì puoi usare il loro servizio di messaggistica che è abbastanza facile da usare. La classe che ha bisogno di informazioni invia semplicemente un messaggio al sottoscrittore e questi a loro volta possono inviare tutti i dati necessari. Penso che questo sia il modo più semplice per gestire la comunicazione.

Answer 3

oltre alle ans fornite dal IVAN .. se guardiamo a una visione di livello superiore senza tutte quelle terminologie allora probabilmente si dovrebbe creare una classe statica che avrebbe server come InMemoryStorage e definisce i campi su di esso per salvare le informazioni
questo ciò che si avrà il controllo completo su ciò che viene condiviso e più componenti possono cambiarlo
Inoltre è possibile definire getter e setter e generare un evento ogni volta che la proprietà viene modificata in modo che forme diverse o finestre (viste) possano sottoscrivere il cambiamento e agire di conseguenza

Answer 4

Un'altra opzione è considerare le classi come servizi. Collegale a un'interfaccia e quindi utilizza dependency injection (alias Inversion of Control) per creare il grafo degli oggetti (Dì al contenitore IoC che vuoi un frmSomething e determinerà quali servizi/classi di cui ha bisogno e istanziali come appropriato).

Questo significa che:

• si hanno sempre e solo al codice contro un non un'interfaccia un'implementazione
• il codice è debolmente accoppiati (è possibile scambiare un OldTranslator per un NewTranslator e fintanto che entrambi rispettino alla stessa interfaccia, nulla deve essere modificato tranne la configurazione del contenitore)
• è possibile sviluppare funzionalità di alto livello che si basano su servizi che non sono stati ancora scritti e il codice verrà compilato
• Si può cambiare molto facilmente il modo in cui funziona la tua app, in fase di esecuzione, se necessario, modificando le classi/i servizi registrati nel tuo contenitore.

Dai un'occhiata a Unity per il contenitore DI supportato da MS. Castle Windsor è un'alternativa popolare, ma ce ne sono molti altri

Vale la pena notare che passare una "Copia" della finestra principale in giro come hai detto non è una brutta cosa - Stai passando solo actralmente un riferimento (effettivamente un puntatore) alla finestra principale (poiché qualsiasi cosa più complessa delle primitive reali sono tipi di riferimento). Ciò significa che c'è pochissimo overhead qualunque