C# La mejor manera de comunicarse entre las clases

Question

Ahora estoy codificando una aplicación y estoy pensando que tiene que haber una mejor solución para lo que estoy haciendo en este momento.

Tengo una ventana principal que manejará la configuración del programa. Luego tengo más clases y ventanas. Por ejemplo, una clase de controlador de idioma y una forma que maneja la entrada del usuario necesaria para la "función principal".

Sin embargo, hasta ahora siempre tengo que pasar mi ventana principal a cada una de estas clases, porque el manejador de lenguaje debe poder cambiar las cadenas de la ventana principal. Y la otra forma también debería poder pasar datos a la ventana principal.

Si imaginamos que habrá muchas más clases y cada clase necesita una copia de la ventana principal, esto consumiría muchos recursos dependiendo del "tamaño" de la ventana principal.

Entonces, ¿hay una manera mejor/más eficiente de comunicarse entre estas clases.

Answer 1

La forma común de hacerlo es usar observer pattern, que en .NET es events system. Dicho simplemente, sus clases se suscriben a los eventos de los demás y realizan una acción cuando se produce un evento. Como se menciona en el comentario, las referencias aprobatorias no son pesadas en la memoria, pero dan como resultado un acoplamiento estrecho entre las diferentes piezas de su código: el patrón del observador aborda ese problema.

Answer 2

Le sugiero que utilice Galasoft o Prism implementaciones MVVM. Allí puede usar su servicio de mensajería, que es bastante fácil de usar. La clase que necesita información solo envía un mensaje al suscriptor y ellos a su vez pueden enviar toda la información necesaria. Creo que esta es la forma más fácil de manejar la comunicación.

Answer 3

además de las dadas por la American National Standard IVAN .. si nos fijamos en una vista de nivel superior sin todas esas terminologías entonces usted probablemente debería crear una clase estática que haría servidor como InMemoryStorage y define los campos en él para guardar información
este lo que tendrá control total sobre lo que se comparte y los componentes múltiples pueden cambiarlo
Además, puede definir getters y setters y generar un evento cada vez que se cambie la propiedad para que diferentes formularios o ventanas (vistas) puedan suscribirse al cambio y actuar en consecuencia

Answer 4

Otra opción es considerar sus clases como servicios. Codifíquelos en una interfaz y luego use dependency injection (también conocido como Inversión de control) para compilar el gráfico de objetos (Usted le dice al contenedor IoC que desea frmSomething y determinará qué servicios/clases necesita y los creará una instancia según corresponda).

Esto significa que:

• para que sólo tenga que codificar en contra de una interfaz no una implementación
• su código está acoplado libremente (se puede intercambiar un OldTranslator para un NewTranslator y siempre y cuando los dos se cumplen a la misma interfaz, no se debe cambiar nada excepto la configuración del contenedor)
• puede desarrollar funciones de alto nivel que se basan en servicios que aún no se han escrito y su código compilará
• Usted puede cambiar fácilmente cómo funciona su aplicación, en el tiempo de ejecución si es necesario, cambiando las clases/servicios que están registrados en su contenedor.

Eche un vistazo a Unity para el contenedor MS-Supported DI. Castle Windsor es una alternativa popular, pero hay muchas más

Vale la pena señalar que no es malo pasar una "Copia" de la ventana principal, como dijiste, solo estás pasando una referencia (efectivamente un puntero) a la ventana principal (ya que cualquier cosa más compleja que las primitivas reales son tipos de referencia). Esto significa que hay muy pocos gastos generales