¿Es malo intentar y tener clases distintas de main/form1 que interactúan entre sí?

Question

Estoy tratando de aprender la forma correcta de usar clases en mi código, cuando no es algo obvio como un conjunto de clientes, perros que heredan de animales, etc.

He roto grandes secciones de código en "características" como Installer.cs, Downloader.cs, UiManager.cs. La única forma en que puedo encontrar que esas clases interactúen con las propiedades y los métodos de los demás es hacer que sean estáticas, lo que me han dicho en otra pregunta es el camino equivocado.

Así que mi problema es de 3 cosas:

1. Hay una manera de hacer clases de hablar unos con otros que simplemente no entiendo todavía.

2. Las clases nunca deben tratar de hablar entre ellas, sino realizar acciones únicas y luego devolver algo a main/form1, que la clase principal puede usar para pasar a otra clase para una acción única.

3. Las clases son realmente solo útiles para hacer muchas instancias, y hay otra estructura completamente que necesito aprender para abstraer grandes porciones de funcionalidad de la clase principal.

Todos los tutoriales que puedo encontrar y conferencias que miro parecen a decir solamente cómo las clases de trabajo, pero no cuándo y cómo utilizarlos en un producto real.

EDITAR - Un ejemplo más específico:

decir que tengo una cadena que es fundamental para la aplicación completa, y tiene que ser visto y/o modificado potencialmente por cada clase. ¿Cómo muevo esa información alrededor del código sin tener todo en una clase o hacerlo estático?

No veo la manera de dejar que la cadena viva en Form1 sin hacerla estática (porque todos los eventos de formulario y funciones necesitarían poder verla para pasarla a una clase).

No veo la manera de poner la cadena en otra clase sin tener que hacer que la cadena y toda la clase sean estáticas, para que otras clases puedan ver en ella.

Quizás haya algo que me falta acerca de crear instancias de las clases y hacer que los objetos interactúen entre ellos.

Answer 1

Creo que todas sus intuiciones son correctas.

1. No, no lo hay. Estático o instancia.

2. Es una opción de diseño (y hay mucho por ahí). Soy pragmático, por lo que considero que un patrón de diseño que genera un código de spaguethi es una mala elección de patrón de diseño. Pero un patrón de diseño incorrecto para un proyecto puede ser un buen patrón de diseño para otro proyecto. Intenta leer el libro de Head First Design Pattern.

3. Sí, hay interfaces y clases abstractas.

Unos cuantos pensamientos:

No creo que el uso de métodos estáticos o clases debe ser evitado. Lo que debe evitarse es el uso erróneo de un método o clase estático, como el uso erróneo de todo dentro de un idioma. Pero es muy difícil definir qué es un uso erróneo de una estática, y dado que los métodos o clases estáticos son particularmente peligrosos, a la gente le gusta decir que se debe evitar la palabra clave estática. Un método estático estará en la memoria a menos que finalice su aplicación, por lo que si no dispone de una conexión dentro de un método estático, tendrá un mal día.

Tengo un proyecto de utilidad, y dentro del proyecto de utilidad tengo una clase de datos. La clase de datos proporciona acceso a la base de datos. Es una clase estática. ¿Por qué?

Bueno, antes que nada, es estático porque la cadena de conexión proviene del webconfig. Así que tengo un constructor estático (se ejecuta una vez cuando se inicia la aplicación y se menciona la clase) que lee el archivo webconfig y almacena la cadena en una variable de miembro privada estática. Creo que es mucho mejor que leer el archivo webconfig y crear una variable de ámbito 10 biliones por día. Los métodos son estáticos porque son lo suficientemente simples, lo que significa que no necesitan mucha configuración para funcionar, solo necesitan algunos parámetros y solo se usan en el proyecto de acceso a datos. Todos los usuarios de mi sitio web están usando la misma instancia del método (la estática), pero todos usan el método estático con diferentes parámetros, por lo que obtienen diferentes respuestas (comparten el conducto, pero beben agua diferente). Solo es necesario tener cuidado adicional dentro del método para limpiar todo (deseche cada instancia del ámbito), porque si no lo hace permanecerán en la memoria. Y finalmente, mi negocio se trata de la manipulación de datos, una clase de datos no estáticos significa mucho más uso de memoria que uno estático (el uso de la CPU es casi el mismo en ambos patrones).

public abstract class Data 
{ 

    [...] 

    static Data() 
    { 
     #if DEBUG 
      _Connection = ConfigurationManager.AppSettings["debug"]; 
     #endif 

     #if RELEASE 
      _Connection = ConfigurationManager.AppSettings["release"]; 
     #endif 

     [...] 
    } 

    [...] 

} 

En el final del día yo uso estática cuando:

1. Si es lo suficientemente sencillo (que puedo controlar todos los aspectos);
2. Si es lo suficientemente pequeño (yo uso los métodos de extensión para las validaciones, y son estáticos) y;
3. Si es muy usado.

Además de eso, utilizo capas para organizar mi proyecto (patrón poco + fábrica). Tengo un proyecto de utilidad, luego un proyecto modelo de entidad, luego un proyecto de acceso, luego un proyecto de lógica de negocios, luego un sitio web, una API, un administrador, etc. Las clases en el proyecto de utilidad no interactúan entre sí, pero sí las clases dentro del proyecto de modelo de entidad (una clase puede tener una instancia de otra clase dentro de ella). El proyecto modelo de entidad no interactúa con el proyecto de utilidad porque tienen el mismo nivel, se relacionan entre sí en otro nivel, en el proyecto de acceso, pero es más intuitivo en un proyecto de manipulación de datos.

Answer 2

Clases hablar con entre si cuando tienen una referencia, con el fin de A para pasar un mensaje a B, A necesita una referencia a B (ya sea una instancia o referencia estática)

clases pueden ya sea hablar el uno al otro o devolver información a otra clase que controlls todo el proceso (esto es en realidad un patrón de diseño)

para abstraer información de la clase principal (o cualquier clase) dispone de interfaces y clases abstractas

el libro los patrones de diseño de The Gang of Four es una lectura obligada en este caso. Otra cosa a tener en cuenta es la simplicidad de su diseño, algunas veces tratando de ajustarse a un patrón de diseño porque puede terminar creando más código de spaguethi. Como regla general, siempre trate de separar la funcionalidad de presentación de la lógica, y piense en las clases como personas hablando entre sí y realizando trabajos (es un poco raro, pero a veces me ayuda a pensar de esta manera)