Si la función es "pura" no veo problemas. Una función pura solo funciona en los parámetros de entrada y proporciona un resultado basado en eso. No depende de ningún estado global o contexto externo.
Si miro tu propio ejemplo de código:
public class Class1
{
public static string GetSomeString()
{
// do something
}
}
Esta función no toma ningún parámetro. Por lo tanto, probablemente no sea puro (la única implementación pura de esta función sería devolver una constante). Supongo que este ejemplo no es representativo de su problema real, simplemente estoy señalando que probablemente esta no sea una función pura.
Tomemos un ejemplo diferente:
public static bool IsOdd(int number) { return (number % 2) == 1; }
No hay nada de malo en que esta función sea estática. Incluso podríamos convertir esto en una función de extensión, permitiendo que el código del cliente sea aún más legible. Las funciones de extensión son básicamente un tipo especial de funciones estáticas.
Telastyn menciona correctamente la concurrencia como un problema potencial con los miembros estáticos. Sin embargo, dado que esta función no usa el estado compartido, aquí no hay problemas de concurrencia. Mil hilos pueden llamar a esta función simultáneamente sin ningún problema de concurrencia.
En el marco .NET, los métodos de extensión existen desde hace bastante tiempo. LINQ contiene muchas funciones de extensión (por ejemplo, Enumerable.Where () , Enumerable.First () , Enumerable.Single () , etc.). No los vemos como malos, ¿verdad?
Las pruebas unitarias a menudo pueden beneficiarse cuando el código usa abstracciones reemplazables, lo que permite que la prueba unitaria reemplace el código del sistema con un doble de prueba. Las funciones estáticas prohíben esta flexibilidad, pero esto es principalmente importante en los límites de la capa arquitectónica, donde queremos reemplazar, por ejemplo, una capa de acceso a datos real con una capa de acceso a datos falsa .
Sin embargo, cuando se escribe una prueba para un objeto que se comporta de manera diferente, dependiendo de si algún número es par o impar, realmente no necesitamos poder reemplazar la IsOdd()
función con una implementación alternativa. Del mismo modo, no veo cuándo necesitamos proporcionar una Enumerable.Where()
implementación diferente con el propósito de probar.
Así que examinemos la legibilidad del código del cliente para esta función:
Opción a (con la función declarada como método de extensión):
public void Execute(int number) {
if (number.IsOdd())
// Do something
}
Opción b:
public void Execute(int number) {
var helper = new NumberHelper();
if (helper.IsOdd(number))
// Do something
}
La función estática (extensión) hace que la primera parte del código sea mucho más legible, y la legibilidad es muy importante, así que use funciones estáticas cuando sea apropiado.