Variables globales v Configuración en C#

Question

He leído en varios lugares que tener variables con alcance global, es decir, una clase estática pública con miembros estáticos, se considera ir en contra de la filosofía de OO, y no es un buen diseño. (Por ejemplo, he visto comentarios como: "Si está utilizando un sistema global, no lo está haciendo bien". O palabras para ese efecto.)

Pero, si usa el mecanismo de Configuración proporcionado por Visual Studio, por ejemplo "Settings.Default.MySetting", etc., esto está disponible globalmente en toda una aplicación, entonces, ¿cómo difiere esto de usar una clase estática pública?

Además, los mismos resultados se pueden lograr utilizando un objeto singleton, pero esto también provoca varias opiniones, por decir lo menos.

Las variables globales son TAN útiles, (Módulo VB, ¿alguien?), Pero estoy tratando de enseñarme cómo hacer esto OO malarky correctamente, entonces, si las variables globales huelen mal desde el punto de vista OO, es una alternativa?

Estoy particularmente interesado en las opiniones de las personas sobre el uso de la funcionalidad 'Configuración'. ¿Esto se considera un buen diseño OO?

Gracias por cualquier comentario.

Answer 1

Los métodos estáticos y otros miembros no son malas prácticas por sí mismos. Es solo que las personas menos familiarizadas con los conceptos OO tienden a ensuciar su código con métodos estáticos, propiedades y campos en todas partes, sin darse cuenta de cuáles son las consecuencias.

Generalmente, para cosas como configuración de configuración, clases de ayuda y utilidad, fábricas abstractas, singletons, etc., tener miembros estáticos es perfectamente aceptable.

Answer 2

Una clase o miembro público estático no siempre es una mala idea (incluso si no es perfectamente OO). Muchos buenos diseños OO usan un miembro estático público para cosas como Loggers o Settings (como usted señala). Un buen ejemplo de cómo hacer esto de forma OO es el Static Gateway.

Answer 3

Las variables globales, como los gotos, son algo que deben evitar todos los principiantes, pero que son extremadamente útiles para un programador avanzado.

Yo diría que si no se siente seguro y no tiene una razón específica y justificada por la cual es una buena aplicación de ellos, no los use. Master OO antes de recurrir a variables globales.

Answer 4

El mecanismo de configuración ... hmm ...

Miro a aquellos principalmente como parte del medio ambiente. Me gusta el sistema operativo o el tiempo, pero para la aplicación. No son realmente "variables" como lo que declararías durante un INIT.

Sin embargo, podría envolver un objeto a su alrededor y solo acceder a ellos a través de ese objeto, en lugar de leerlos cada vez que fueran necesarios en tiempo de ejecución. No lo he probado, pero es probable que sea un lavado de rendimiento (o negativo para leerlos en bruto si no se hace una buena gestión de la memoria).

Eventualmente, a medida que las aplicaciones maduran, cosas como esta terminan envolviendo objetos de todas formas. Mi regla es que, cada vez que empiezo a pensar, "nah, esto es demasiado simple, demasiado atómico, y no requerirá un objeto ..." esa es mi clave para convertirlo en un objeto.

Answer 5

En C# va a ser difícil ir contra el buen diseño de OO porque no puede alejarse de OO. No es como C++ donde se puede mezclar y combinar estructurado con programación OO - el ámbito en el que a menudo ocurren este tipo de argumentos. Los miembros estáticos en una clase son OO. También lo son las Configuraciones generadas por Microsoft porque la generación de código crea encapsulamiento OO para ellas o al menos un "contenedor de objetos" a su alrededor. Entonces nunca son variables globales porque eso no existe en C#, son solo miembros estáticos en las clases, nada allí que no sea OO.

Si el argumento es sobre singleton vs miembros estáticos, entonces está enfrentando un argumento OO contra otro argumento OO.

Luego siempre está el punto de vista filosófico versus el punto de vista práctico. En la mayoría de los reinos, el punto de vista filosófico ideal que se está implementando en realidad no vale la pena por sí solo a excepción del estudio académico. El mundo real necesita soluciones reales, soluciones mixtas.