code-design - programacion - metodos estaticos c#
¿Deberías evitar las clases estáticas? (7)
¿Las clases estáticas se consideran una mala práctica? Leí un artículo sobre esto hace un par de días (no lo puedo encontrar, lo siento) que básicamente dice que tener clases estáticas (especialmente esas clases de "ayudantes") suele ser un signo de código incorrecto. ¿Es correcto, y si es así, por qué razones?
¿Significa que "el uso de clases estáticas es incorrecto" (en cuyo caso el artículo es incorrecto) o "las clases estáticas se encuentran a menudo en código mal escrito" (en cuyo caso no se dice que las clases estáticas en sí mismas son malas, sino que a veces se usan incorrectamente)
Las funciones estáticas son más eficientes que las no estáticas porque no es necesario crear una instancia de un objeto para usarlas o pasar un puntero ''this'' a las llamadas de método.
El uso de clases estáticas para mantener variables globales es un asunto diferente, en cuyo caso la regla subyacente no es que "lo estático es malo", sino que "lo global es malo".
Aquí hay algunos enlaces a algunas publicaciones de blogs de Google Test sobre por qué los métodos estáticos pueden afectar la capacidad de prueba de su código, y por qué los métodos estáticos (que son la parte mala de las clases estáticas) introducen todo tipo de acoplamientos e interacciones entre componentes potencialmente sorprendentes.
Creo que el argumento general es contra mantener el estado mutable en clases estáticas y básicamente usarlas como variables globales. No hay nada malo con los métodos de ayuda estática en una clase estática.
Y en cuanto a por qué las variables globales son malas, estoy seguro de que entre aquí y google encontrarás medio millón de páginas y publicaciones de blog al respecto.
El abuso de clases estáticas puede considerarse una mala práctica. Pero también puede el abuso de cualquier característica del lenguaje.
No hago distinción entre una clase no estática con solo métodos estáticos y una clase estática. De hecho, son lo mismo, excepto que las clases estáticas permiten que el compilador imponga la intención de los desarrolladores (sin instanciar esta clase, sintaxis conveniente para acceder a su funcionalidad, etc ).
Como usted dice, una proliferación de clases de "Ayudantes" puede causarle problemas (diseño, facilidad de mantenimiento, legibilidad, capacidad de descubrimiento, otras habilidades ...). No hay discusión aquí. ¿Pero puedes argumentar que una clase de "Ayudante" nunca es apropiada? Lo dudo.
De hecho, el uso responsable de clases estáticas puede tener grandes beneficios para su código:
- La clase estática
Enumerableproporciona un conjunto de métodos de extensión que la mayoría de nosotros hemos llegado a amar. Son un conjunto lógico de funcionalidad / lógica empresarial que no se relaciona con una instancia de ningún tipo en particular. - Servicios proporcionados por el entorno / contexto: por ejemplo, registro, configuración (a veces)
- Otros (que no puedo pensar en este momento :))
Así que no, en general no es una mala práctica. Solo úsalos sabiamente ...
Hay necesidades donde tienes una clase de utilidad donde todos los métodos son estáticos. En ese caso, si hace que la clase sea estática, indicará claramente su intención. Y al menos en C # no puede tener métodos no estáticos dentro de una clase estática.
No, no es realmente correcto.
Hay muchas funciones que no son específicas de una instancia de un objeto y que no requieren estado. Por ejemplo, considere las funciones ''matemáticas''.
Casi todos los idiomas tienen algo como:
y = Math.round(x);
Así que la función ''redonda'' es estática. Usted podría, si estuviera loco, argumentar por algo como (C #):
class RoundFunction<T> : GeneralMathFunction<T>
{
public override T Operate (params object[] variables) {
..
}
}
Pero, en mi humilde opinión, sería un poco raro hacerlo.
Ciertamente, hay un momento en el que demasiadas funciones estáticas son un signo de que algo salió mal, pero, dentro de lo razonable, no es "malo".
Utilizo clases de utilidad estática todo el tiempo en mi código para los métodos que se llaman con bastante frecuencia, pero sería una molestia crear una instancia. Un ejemplo sería una clase de registro simple como:
public static class Logging
{
public static UpdateAction(int id, object data)
{
SqlConnection connection = new SqlConnection("conn string from config file");
// more logic here...
}
}
Ahora, de ninguna manera tengo esas clases y métodos que almacenen algún tipo de estado global, ya que eso puede llevar a problemas de concurrancia enormes y, en general, es simplemente un mal diseño.
Así que no evite las clases estáticas, evite que esas clases estáticas mantengan algún tipo de estado global.