2011-02-10 20 views
7

Concettualmente, è appropriato utilizzare un metodo statico (C#) quando il metodo assumerà solo input e riformatterà l'input come output? Per esempio:Uso appropriato del metodo statico

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

Se dovessi avere un paio di questi tipi di metodi, sarebbe una "utilità" classe statica essere una buona idea?

+2

FYI: i parametri del metodo devono iniziare con una lettera minuscola. (ad es. 'inputString') –

+1

I nomi dei metodi dovrebbero in realtà iniziare con una lettera maiuscola, anche se si vogliono seguire le regole standard dei casing C#;) –

+1

E i nomi dei metodi dovrebbero iniziare con una lettera maiuscola (es.' FormatString'), assumendoti Stai seguendo le convenzioni di codifica .NET: -> http://msdn.microsoft.com/en-us/library/ms229045.aspx – Pandincus

risposta

3

Sono d'accordo con le altre risposte finora che ha certamente un senso molto del tempo.

A volte, potresti volerti dare un po 'più di flessibilità definendo un'interfaccia e implementandola con i metodi di istanza. Questo ti dà la possibilità di utilizzare diversi metodi nel tuo codice lungo la strada.

Ecco un esempio di cosa intendo. Diciamo che si sta utilizzando questo metodo di tuo formatString a qualche codice da qualche che assomiglia a questo:

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

bene, questo è grande. (In realtà, è stupido, ma qualunque sia - solo per illustrazione!) Ma potresti rendere un tale metodo più flessibile accettando un'interfaccia , di cui potresti avere varie implementazioni che forniscono diversi tipi di formattazione:

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)); 
    } 
} 

Poi, invece di StringUtils essere una classe di utilità statica, sarebbe semplicemente uno implementazione di una classe che offre un modo per formattare un certo tipo di oggetto (nel tuo caso, string oggetti; nel mio esempio, questi immaginari DataField oggetti).

Quindi questo è tutto un modo molto prolisso di dire, dipende. Se stai cercando la massima flessibilità lungo il percorso, forse, dovresti prendere in considerazione l'implementazione di un'interfaccia invece di utilizzare una classe helper statica.

Si noti che nel mio esempio sopra, un altro modo completamente accettabile di affrontare il problema potrebbe essere stato accettare un delegato Func<T, string> invece di questa ipotetica interfaccia IFormatter<T>. Questa è principalmente una scelta stilistica, secondo me. Ma spesso le interfacce diventano più realistiche quando ci sono più comportamenti che si desidera personalizzare; Ad esempio, definire i metodi che accettano 3, 4 o più delegati può diventare rapidamente ingombrante rispetto all'accettazione di una singola interfaccia.

+0

Dan, mentre sono d'accordo con lo spirito di ciò che stai dicendo (come faccio di solito con ciò che pubblichi), non pensi che questa risposta potrebbe essere solo un po 'eccessiva? ;) –

+1

@Adam: Haha ... si. Devo dire, però, che personalmente ho imparato una tale somma assurda da SO (semplicemente guardando indietro su alcune delle mie vecchie domande, è davvero stupefacente quanto fossi ignaro) che ritengo sia giusto cercare di insegnare ad altri utenti quando possibile. Certo, era una domanda semplice; questa risposta lascia molto più del PO richiesto. Ma se gli offre qualche nuova idea su cui riflettere, allora dico che è una vittoria. Se no ... oh, beh, cinque minuti in malora. Non è peggio che guardare qualche spot televisivo;) –

+0

È buffo che sia Adam e Dan a discutere di questo, poiché ero molto lacerato su quale delle due risposte accettare. @ Adam - post veloce, conciso e quello che stavo cercando. @ Dan - Hai convalidato che non ero pazzo, e mi ha dato un po 'da masticare. Apprezzo molto lo sforzo che voi esponete. Che comunità straordinaria ... – JayWD

2

Se si stanno rendendo pubblici questi, allora sì, potrebbe essere potenzialmente meglio creare una classe di utilità di qualche tipo.

Detto questo, proverei a renderlo il più possibile "generale", poiché altrimenti tendono a diventare rapidamente non mantenibili.

3

Sì, se si dispone di diversi metodi statici generalmente correlati, metterli insieme in una classe di utilità statica è una buona idea.

Se si sta parlando di convenzione, è anche la pena notare che le convenzioni di denominazione nella maggior parte delle chiamate di codice .NET per i membri di Pascal-carter pubblici (così FormatString invece di formatString) e dei parametri di cammello-carter e campi (così inputString invece di InputString).

2

Sì, i metodi statici nel modo in cui vengono utilizzati in C# sono molto simili all'idea di C++ di "funzioni libere". Succede solo che C# non ha funzioni libere. Eric Lippert ha un post interessante qui da qualche parte del perché questo è il caso. Una classe statica è usata per raggruppare funzioni di utilità simile e sarebbe appropriata se tu avessi molti di questi che erano simili.

+0

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

2

Sì, va bene, la classe funzionerà quindi come una "libreria" di funzioni correlate. Le tue altre scelte per questo sarebbe di inquinare il namespace globale con varie funzioni o di creare un Singleton che non sarebbe necessario poiché non c'è uno 'stato' per rendere conto di ...

1

Personalmente mi sporgo più verso l'uso di un metodo di estensione, ancora statico però;)

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

Sì, è possibile farlo. O potresti creare un metodo di estensione della stringa.

msdn extension methods

Per il vostro esempio di cui sopra, vorrei utilizzare il formattatore stringa invece di linea concatenazione.

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

È se quella particolare formattazione sarebbe utile in più di un posto nel codice.

Se avesse senso solo all'interno di una classe specifica, preferirei utilizzare un metodo privato (statico o istanza, non farebbe differenza).

Le classi di utilità sono una cosa utile. L'unica cosa da fare attenzione è non usarli troppo spesso. Se la maggior parte del tuo codice è in classi di utilità, allora stai facendo qualcosa di sbagliato. Ma il fatto di definire un codice comune nei metodi di supporto è un uso perfettamente giustificato.

2

È possibile utilizzare un metodo di estensione per estendere la classe String. Renderebbe il codice di chiamata un po 'più ordinato, ma alla fine è solo una questione di gusto personale.

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

A mio parere la risposta è sì, si metterebbero questi metodi in una classe Utilità (Util). Su un'applicazione Java basata sul web su cui sto lavorando attualmente abbiamo in realtà 3 classi Util ognuna delle quali comprende solo metodi statici simili a quelli che hai mostrato. Il motivo per cui abbiamo 3 è uno solo per i metodi Util del client, uno per il solo server e un terzo per i metodi Usil condivisi.

A seconda della tua app, potresti ritrovarti con qualcosa di simile.

Per inciso, se vuoi saperne di più su quando utilizzare le classi statiche in C#, dai un'occhiata a here.

Spero che abbia risposto alla tua domanda sufficientemente.