¿las clases estáticas se consideran malas prácticas? Leí un artículo sobre esto hace un par de días (no lo encuentro, lo siento) que básicamente decía que tener clases estáticas (especialmente esas clases 'auxiliares') son típicamente un signo de código incorrecto. ¿Es correcto, y si es así, por qué?¿Debería evitar las clases estáticas?
El abuso de clases estáticas se puede considerar una mala práctica. Pero también lo puede hacer el abuso de cualquier característica del idioma.
No distingo entre una clase no estática con solo métodos estáticos y una clase estática. En realidad son la misma cosa, excepto que las clases estáticas le permiten al compilador hacer cumplir la intención del desarrollador (sin instanciar esta clase, sintaxis conveniente para acceder a su funcionalidad, etc).
Como dices, una proliferación de clases de "Ayuda" puede causarte problemas (diseño, mantenimiento, legibilidad, capacidad de descubrimiento, otras habilidades ...). No hay argumento aquí. ¿Pero puede argumentar que una clase "Ayudante" es nunca apropiada? Lo dudo.
De hecho, el uso responsable de las clases estáticas puede tener grandes beneficios a su código:
Enumerable proporciona un conjunto de métodos de extensión mayoría de nosotros hemos llegado a amar. Son un conjunto lógico de funcionalidad/lógica comercial que no está relacionado con una instancia de ningún tipo en particular.Así que no, en general, no está mal práctica. Solo úselos con prudencia ...
Una diferencia (a lo anterior) es la capacidad de adaptarse mejor a los cambios a lo largo del tiempo. Al usar objetos en su lugar, puede iniciar la misma clase con dos configuraciones diferentes y así lograr una mayor encapsulación. – Teson
Nah, 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 lenguajes tienen algo como:
y = Math.round(x);
Así la función 'redondo' es estático. Se podría, si estuviera loco, discutes por algo así 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 para hacerlo.
Ciertamente, hay un momento en que demasiadas funciones estáticas son un signo de que algo salió mal, pero, dentro de lo razonable, no es "malo".
Existen necesidades en las que tiene una clase de utilidades donde todos los métodos son estáticos. En ese caso, si haces que la clase sea estática, indica claramente tu intención. Y al menos en C# no puede tener métodos no estáticos dentro de una clase estática.
Creo que el argumento general es en contra de mantener el estado mutable en clases estáticas, y básicamente usarlas como variables globales. No hay nada de malo con los métodos estáticos de ayuda en una clase estática.
Y en cuanto a por qué las variables globales son malas, estoy seguro de que aquí y en google encontrará medio millón de páginas y publicaciones en el blog al respecto.
sí, eso es lo que * reclama * pero no es lo que realmente muestra. Las clases estáticas (como las matemáticas) NO son el equivalente de las variables globales, son el equivalente de las constantes * globales *. Incluso con parámetros, esto aún no es lógicamente diferente de las matrices de constantes globales, listas, etc. No recuerdo mucho problema con ellos. – RBarryYoung
He editado mi respuesta para indicar que me refiero a estado mutable en una clase estática, no constantes. – Davy8
Aquí hay algunos enlaces a algunas publicaciones del blog de Google sobre por qué los métodos estáticos pueden dañar la capacidad de prueba de su código, y por qué los métodos estáticos (que son la parte negativa de las clases estáticas) introducen todo tipo de acoplamiento y interacción entre componentes.
todos estos artículos están escritos por el mismo tipo. Resulta que es solo un fanático de Ruby en una diatriba. Todo su argumento se resume en sus propias palabras: "El problema básico con los métodos estáticos es que son código de procedimiento. No tengo idea de cómo probar el código de procedimiento". Guau. 50 años de metodología de prueba precedieron a este tipo y él no sabe nada de eso. Lo único que me imagino sería más embarazoso que admitir públicamente que esto sería si el resto de nosotros basara nuestras metodologías de diseño y prueba en las opiniones de alguien que aparentemente durmió en la universidad. – RBarryYoung
Es un idiota. Él afirma que después de escribir un método estático como Abs(), decidirá agregar mucha lógica comercial adicional dentro de él que no podrá probar. El punto cuando se prueba una unidad lógica no es cuánto trabajo se hace dentro de ella, sino que proporciona las salidas apropiadas para todas sus posibles entradas. Si agrega más código (estático o no), solo necesita agregar más pruebas de unidad. –
Rbarry: Yo diría que es más fanático de OO que un fanático de Ruby, y su publicación * fue * etiquetada como una farsa :) –
utilizo clases de utilidad estática todo el tiempo en mi código para los métodos que se llaman muy a menudo, pero sería un dolor para instanciar. 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 hacer alguna vez tengo esas clases y métodos de almacenar cualquier tipo de estado global, ya que puede dar lugar a enormes problemas concurrancy y en general es sólo una mala diseño.
Así que no evite las clases estáticas, simplemente evite que esas clases estáticas mantengan algún tipo de estado global.
¿Cómo prueba sus métodos estáticos? Si los refactoriza, ¿cómo se asegura de que no haya introducido regresiones? – mcwyrm
Significa "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 está diciendo que las clases estáticas en sí mismas sean malas , pero 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 a métodos.
El uso de clases estáticas para contener variables globales es una cuestión diferente, en cuyo caso la regla subyacente no es que "las estadísticas son malas", sino que "las globales son malas".
¿Se refiere en su lugar a "método estático"? Los ejemplos a continuación, como Math.round, son ejemplos de métodos estáticos, pero la clase Math en sí misma no es estática. –
No, quise decir clases estáticas. Agregué un comentario a la publicación de sedoso para aclarar. – Alex
Definitivamente sería más fácil para nosotros refutar/estar de acuerdo con el artículo si supiéramos exactamente lo que decía, y si se trataba de un determinado contexto, idioma o filosofía de diseño. –