2011-02-10 32 views
7

Conceptualmente, ¿es apropiado utilizar un método estático (C#) cuando el método solo tomará las entradas y formateará la entrada como la salida? Por ejemplo:Uso apropiado del método estático

public static string FormatString(string inputString){ 
    return "some formatting" + inputString + "Some other formatting"; 
} 

Si tuviera que tienen algunos de estos tipos de métodos, habría una clase estática "utilidad" ser una buena idea?

+2

FYI: los parámetros del método deben comenzar con una letra minúscula. (es decir, 'inputString') –

+1

Los nombres de los métodos realmente deberían comenzar con una letra mayúscula, si usted quiere seguir las reglas estándar de C#; –

+1

Y los nombres de los métodos deben comenzar con una letra mayúscula (es decir,' FormatString'), asumiendo sigue las convenciones de codificación de .NET: -> http://msdn.microsoft.com/en-us/library/ms229045.aspx – Pandincus

Respuesta

3

Estoy de acuerdo con las otras respuestas hasta el momento que sin duda tiene sentido la mayor parte del tiempo.

A veces,, es posible que desee darse un poco más de flexibilidad mediante la definición de una interfaz y su implementación con los métodos de instancia. Esto le da la opción de usar métodos diferentes en su código más adelante.

Aquí hay un ejemplo de lo que quiero decir. Digamos que usted está usando este método formatString de los suyos en algún código en alguna parte que se ve así:

public void DumpToConsole() 
{ 
    foreach (DataField field in m_fields) 
    { 
     Console.WriteLine(StringUtils.formatString(field.ToString())); 
    } 
} 

OK, esto es muy bueno. (En realidad, es estúpido, pero lo que sea -¡sólo para ilustración!) Pero podría hacer que ese método sea más flexible al aceptar una interfaz , de la que puede tener varias implementaciones que proporcionan tipos completamente diferentes de formateo:

public void DumpToConsole(IFormatter<DataField> formatter = null) 
{ 
    // Perhaps you could specify a default. Up to you. 
    formatter = formatter ?? Formatter<DataField>.Default; 

    foreach (DataField field in m_fields) 
    { 
     Console.WriteLine(formatter.Format(field)); 
    } 
} 

Entonces, en lugar de StringUtils ser una clase de utilidad estática, sería meramente uno implementación de una clase que ofrece una manera de dar formato a un determinado tipo de objeto (en su caso, string objetos; en mi ejemplo, éstos imaginaria DataField objetos).

Así que esta es una manera muy larga de decir que depende. Si está buscando una súper flexibilidad en el futuro, quizás, debería considerar implementar una interfaz en lugar de ir con una clase de ayuda estática.

Ten en cuenta que en el ejemplo anterior, otra forma completamente aceptable de abordar el problema podría haber sido aceptar un delegado Func<T, string> en lugar de esta hipotética interfaz IFormatter<T>. Esto es principalmente una elección de estilo, en mi opinión. Pero a menudo las interfaces se vuelven más realistas cuando hay múltiples comportamientos que desea personalizar; es decir, la definición de métodos que aceptan 3, 4 o más delegados puede volverse engorrosa rápidamente en comparación con la aceptación de una sola interfaz.

+0

Dan, aunque estoy de acuerdo con el espíritu de lo que Lo digo (como suelo hacer con lo que publiques), ¿no crees que esta respuesta podría ser un poco * poco * excesiva? ;) –

+1

@Adam: Jaja ... sí. Diré, sin embargo, que personalmente he aprendido una cantidad tan absurda de SO (solo mirando atrás en algunas de mis preguntas anteriores, es realmente sorprendente lo ajeno que estaba) que siento que es correcto tratar de enseñar a otros usuarios cuando sea posible. De acuerdo, era una pregunta simple; esta respuesta cede más de lo que el PO solicitó. Pero si posiblemente le da algunas ideas nuevas para pensar, entonces digo que es una victoria. Si no ... bueno, cinco minutos por el desagüe. No es peor que ver algunos comerciales de televisión;) –

+0

Es curioso que sean Adam y Dan quienes discutan esto, ya que estaba muy indeciso acerca de cuál de sus dos respuestas aceptar. @Adam - publicación rápida, conciso y lo que estaba buscando. @Dan - Validaron que no estaba loco, y me dieron un poco de mordisco. Aprecio mucho el esfuerzo que ustedes están haciendo. Qué comunidad increíble ... – JayWD

2

Si los está haciendo públicos, entonces sí, podría ser mejor crear una clase de utilidad de algún tipo.

Dicho esto, trataré de hacerlo tan "general" como sea posible, ya que de lo contrario, tienden a perderse rápidamente.

3

Sí, si tiene varios métodos estáticos que generalmente están relacionados, juntarlos en una clase de utilidad estática es una buena idea.

Si estás hablando de convenciones, es también digno de mención que las convenciones de nomenclatura en la mayoría de llamadas de código .NET para los miembros entubados-Pascal públicos (por lo FormatString en lugar de formatString) y parámetros de camellos con carcasa y campos (por lo que en lugar de inputStringInputString).

2

Sí, los métodos estáticos en la forma en que los usa en C# son muy similares a la idea de C++ de "funciones gratuitas". Da la casualidad que C# no tiene funciones gratuitas. Eric Lippert tiene una publicación interesante por aquí de por qué ese es el caso. Una clase estática se utiliza para agrupar funciones de utilidad similar y sería apropiado si tuviera varios de estos que fueran similares.

+0

http://blogs.msdn.com/b/ericlippert/archive/2009/06/22/why-doesn-tc-implement-top-level-methods.aspx –

2

Sí, eso está bien, su clase actuará como una 'biblioteca' de funciones relacionadas. Sus otras opciones para esto serían contaminar el espacio de nombres global con varias funciones o crear un Singleton que sería innecesario ya que no hay un 'estado' que represente ...

1

Personalmente me inclinaría más por el uso de un método de extensión, aún estático;)

public static class StringExtensions 
{ 
    public static string MyFormat(this string input) 
    { 
     return string.Format("some formatting {0} Some other formatting", input); 
    } 
} 
2

Sí, podría hacer eso. O podrías crear un método de extensión de cadena.

msdn extension methods

Para su ejemplo anterior, me gustaría utilizar el formateador de cadena en lugar de la concatenación en línea.

string.Format("some formatting {0} some other formatting", inputString) 
2

Es si ese formato en particular podría ser útil en más de un lugar en el código.

Si tiene sentido solo dentro de una clase específica, entonces prefiero usar un método privado (estático o instancia, no haría la diferencia).

Las clases de utilidad son útiles. Lo único que debe tener cuidado es no usarlos con demasiada frecuencia. Si la mayoría de su código está en clases de utilidad, entonces está haciendo algo mal. Pero factorizar un código común en los métodos de ayuda es un uso perfectamente justificado.

2

Puede utilizar un método de extensión para extender la clase String. Haría que el código de llamada fuera un poco más ordenado, pero al final es solo una cuestión de gusto personal.

public static string MyWeirdFormat(this string str) 
    { 
     return string.Format("{0} is weird",str); 
    } 

    public static void Test() 
    { 
     string myString = "ABCD"; 
     string weirdString = myString.MyWeirdFormat(); 
    } 
2

En mi opinión, la respuesta es sí, pondría estos métodos en una clase de utilidad (Util). En una aplicación basada en la web de Java en la que estoy trabajando actualmente tenemos 3 clases de Util, cada una de las cuales consta de solo métodos estáticos similares al que usted ha mostrado. El motivo por el que tenemos 3 es uno para los métodos Util únicamente del cliente, uno solo para el servidor y el tercero para los métodos Util compartidos.

Dependiendo de la aplicación, puede terminar con algo similar.

Como un aparte, si desea obtener más información sobre cuándo usar clases estáticas en C#, eche un vistazo a here.

Espero que haya respondido su pregunta lo suficiente.

Cuestiones relacionadas