¿Son malvados los métodos y las variables estáticas de C#? Derek Comartin lo explica (Desglose en vídeo)

¿Qué hace que un método estático sea problemático?

Al principio del vídeo, Derek se sumerge en un método estático llamado Is18YearsOrOlder. Este método toma una DateTime birthDate y comprueba si alguien tiene al menos 18 años. Utiliza DateTime.UtcNow para comparar la fecha actual. Bastante sencillo, ¿verdad?

Pero, como señala Derek, este método no es determinista. En el minuto 0:50, destaca que el uso de DateTime.UtcNow significa que el método devolverá resultados diferentes en función del momento en que se ejecute. Es un problema importante en las pruebas unitarias y provoca comportamientos inesperados en el código.

En este caso, aunque el método parece una función pura, no lo es. Derek explica que un método puro debe devolver el mismo valor cada vez que se llama con los mismos parámetros. Pero aquí, la fecha actual sigue cambiando, por lo que el valor de retorno también lo hace.

Esto ilustra cómo un método estático público, aunque conveniente, puede introducir efectos secundarios si depende de datos en tiempo real o del estado del dominio de la aplicación.

Hacer que los métodos estáticos sean comprobables y predecibles

El siguiente punto de Derek es crucial: podemos solucionar el no determinismo eliminando la dependencia de DateTime.UtcNow. En su lugar, Derek muestra cómo inyectar un proveedor de tiempo utilizando una clase estática o una implementación de interfaz. Esto hace que la función sea determinista: se obtiene la misma salida cada vez que se pasa la misma entrada.

En su clase PlaceOrder, introduce un proveedor de fechas falso para poder probar si los pedidos procesados los viernes obtienen un descuento del 50%. De este modo, se evita la codificación rígida de la lógica vinculada a la hora del sistema, lo que hace que el método sea más fiable y comprobable.

Aislando el comportamiento y evitando referenciar métodos estáticos directamente dentro de la lógica de negocio, Derek muestra cómo preservar un código limpio a la vez que se mantiene la comprobabilidad.

Acoplamiento estrecho y métodos estáticos

Derek advierte en este punto que confiar en métodos estáticos a menudo introduce un acoplamiento estrecho. Si utilizas DateTime.UtcNow directamente, estás vinculado a esa implementación; no puedes anularla ni imitarla.

Esto supone un problema porque los miembros estáticos de este tipo son globales en toda la aplicación. Si su código utiliza en gran medida campos estáticos o propiedades estáticas, se hace más difícil cambiar el comportamiento o inyectar dependencias, rompiendo principios clave de la programación orientada a objetos.

También se pierde flexibilidad porque no se puede sustituir ese campo estático por una implementación diferente, como se podría hacer con una variable de instancia o un servicio inyectado.

El problema del estado global con las variables estáticas

Ahora Derek se centra en las variables estáticas, y aquí es donde la conversación se pone seria.

Presenta un ejemplo utilizando una caché estática en una clase Global. Explica que el mayor problema de las variables estáticas es el estado desconocido. En tiempo de ejecución, no puede estar seguro de si su campo estático se ha inicializado. Esta imprevisibilidad es especialmente arriesgada cuando hay un nombre de cadena o int estático mutable implicado.

Este escenario empeora cuando los desarrolladores asumen que sólo hay una copia de esa variable compartida entre hilos y se olvidan de tener en cuenta la seguridad de los hilos.

Seguridad de hilos y campos estáticos en código multihilo

Derek plantea otro problema: el uso de variables estáticas en entornos multihilo. Ofrece un ejemplo de una List estática utilizada simultáneamente con Parallel.For. El código se bloquea porque el campo estático no es seguro para los hilos.

Para solucionarlo, recurre a ConcurrentBag, una colección a prueba de hilos disponible en .NET. Esto permite un acceso seguro a los datos estáticos a través de múltiples hilos.

Su argumento es claro: si utilizas variables estáticas en varios subprocesos, asegúrate de que sean seguras. De lo contrario, su programa puede comportarse de forma impredecible o incluso bloquearse.

Uso seguro de métodos estáticos

A continuación, Derek comparte un uso seguro y eficaz de un método estático: un sencillo método de utilidad MilesToKilometers. Toma un int miles y devuelve un valor double después de la conversión. Este método es determinista: para el mismo valor int, siempre se obtiene el mismo resultado.

Este tipo de método no depende de campos no estáticos, no muta datos compartidos y no implica ningún estado desconocido. Es un buen ejemplo de cómo utilizar correctamente la palabra clave static en C#.

Comprensión de Static en el contexto .NET

En C#, la palabra clave static puede aplicarse a clases, campos, métodos, constructores y propiedades. Derek toca indirectamente el concepto de:

• Clase estática: Clase que no puede instanciarse y que sólo puede contener miembros estáticos.

• Campos estáticos: Declarados con la palabra clave static - sólo existe una copia por dominio de aplicación.

• Constructor estático: Se ejecuta una sola vez cuando se accede a la clase por primera vez.

• Static void Main: El punto de entrada de la mayoría de las aplicaciones de C#, que demuestra cómo los métodos estáticos pueden ser esenciales.

• Static int, static string: Ejemplos de campos estáticos que almacenan datos comunes a todas las instancias de la clase o que, de hecho, no requieren instancia alguna.

A diferencia de los constructores de instancia, que se ejecutan cada vez que se crea un objeto, el constructor estático sólo inicializa los recursos a nivel de clase una vez.

Esta distinción ayuda a los desarrolladores a decidir cuándo utilizar una variable de instancia frente a una variable estática, o cuándo utilizar accesores de propiedad para encapsular variables miembro compartidas.

Comentarios finales de Derek

Derek resume las principales razones por las que los desarrolladores desaconsejan los miembros estáticos:

• Acoplamiento estrecho: estás atascado con el comportamiento de ese método o campo estático.

• Comportamiento no determinista: difícil de probar, fácil de romper.

• Estado mutable global: no se sabe cuál es el valor ni quién lo ha cambiado.

• Problemas de concurrencia: acceso inseguro a datos compartidos en código multihilo.

Sin embargo, como dice Derek, la estática no es mala. Es muy potente cuando se utiliza correctamente, especialmente en funciones de utilidad, constantes compartidas o configuraciones verdaderamente globales. Sólo hay que gestionar el estado con cuidado y evitar depender de comportamientos mutables o específicos del sistema.

Conclusión

Las variables estáticas y los métodos son un arma de doble filo en C#. Como explica claramente Derek Comartin, no son intrínsecamente malas, pero requieren un uso cuidadoso. Utilice campos estáticos y clases estáticas cuando necesite datos compartidos o una funcionalidad que no dependa del estado del objeto. Pero evite utilizarlas para cosas que dependan del tiempo, del estado del sistema o que requieran flexibilidad.

Así pues, antes de crear un objeto o acceder a un campo estático, piense en el alcance, la comprobabilidad, la seguridad de los hilos y si el código necesita una copia o varias instancias.

Vea el vídeo completo de Derek Martin en su canal de YouTube CodeOpinion. Encontrará más información sobre arquitectura limpia, diseño de software y aplicaciones de C# en el mundo real.