Noté que casi cada vez que veo programadores que usan clases estáticas en lenguajes orientados a objetos como C #, lo están haciendo mal. Los principales problemas son obviamente el estado global y la dificultad de intercambiar implementaciones en tiempo de ejecución o con simulacros / stubs durante las pruebas.
Por curiosidad, he visto algunos de mis proyectos seleccionando los que están bien probados y cuando hice un esfuerzo por pensar realmente en la arquitectura y el diseño. Los dos usos de las clases estáticas que he encontrado son:
La clase de utilidad, algo que preferiría evitar si escribiera este código hoy,
El caché de la aplicación: usar una clase estática para eso es simplemente incorrecto. ¿Qué pasa si quiero reemplazarlo por
MemoryCache
Redis?
Al mirar .NET Framework, tampoco veo ningún ejemplo de uso válido de clases estáticas. Por ejemplo:
File
La clase estática hace que sea realmente doloroso cambiar a alternativas. Por ejemplo, ¿qué sucede si uno necesita cambiar a Almacenamiento aislado o almacenar archivos directamente en la memoria o necesita un proveedor que pueda admitir transacciones NTFS o al menos poder manejar rutas de más de 259 caracteres ? Tener una interfaz común y múltiples implementaciones parece tan fácil como usarloFile
directamente, con el beneficio de no tener que reescribir la mayor parte del código base cuando cambian los requisitos.Console
La clase estática hace que las pruebas sean demasiado complicadas. ¿Cómo debo asegurarme dentro de una prueba unitaria de que un método genera datos correctos en la consola? ¿Debo modificar el método para enviar la salida a un objeto de escrituraStream
que se inyecta en tiempo de ejecución? Parece que una clase de consola no estática sería tan simple como una estática, una vez más, sin todos los inconvenientes de una clase estática.Math
la clase estática tampoco es un buen candidato; ¿Qué pasa si necesito cambiar a aritmética de precisión arbitraria? ¿O a alguna implementación más nueva y más rápida? ¿O a un trozo que dirá, durante una prueba de unidad, que un método dado de unaMath
clase fue efectivamente llamado durante una prueba?
En Programmer.SE, he leído:
¿No utiliza "estático" en C #? Algunas respuestas están bastante en contra de las clases estáticas. Otros afirman que "los métodos estáticos están bien para usar y tienen un lugar legítimo en la programación", pero no lo cuecen con argumentos.
Cuándo usar un Singleton y cuándo usar una clase estática . Se mencionan las clases de utilidad, dado que mencioné anteriormente que las clases de utilidad son problemáticas.
¿Por qué y cuándo debo hacer una clase 'estática'? ¿Cuál es el propósito de la palabra clave 'estática' en las clases? El único uso válido que se menciona es un contenedor para métodos de extensión. Excelente.
Aparte de los métodos de extensión, ¿cuáles son los usos válidos de las clases estáticas, es decir, casos en los que la inyección de dependencia o los singletons son imposibles o darán como resultado un diseño de menor calidad y una mayor extensibilidad y mantenimiento?
instanceof
) porque en dos casos IFoo
no hay garantía de que estén respaldados por la misma clase.
YAGNI
, y acepta que si alguna vez necesita un tipo diferente de cadena, sólo obtendrá su IDE para cambiar todos los casos de com.lang.lib.String
que com.someones.elses.String
en toda la base de código.