Quando si passa un nome file a un metodo, dovrei usare FileInfo o un nome file semplice?

Question

Bene, il titolo dice tutto. Quando si passa un nome di file a un metodo, dovrei usare un oggetto FileInfo o un nome file semplice (stringa)? Perché preferirei l'uno all'altro?

Alcuni dei miei colleghi piace scrivere metodo come questo:

• vuoto Export (FileInfo FileInfo)

È meglio di:

• vuoto Export (string filename)

Grazie!

Answer 1

Di solito uso solo uno string - è più semplice nella maggior parte dei casi. In caso contrario, è probabile che crei appena un nuovo FileInfo dalla stringa.

Se si sta creando il metodo, è sempre possibile fornire sovraccarichi per consentire entrambi.

Naturalmente, se si sa che dove avete intenzione di chiamarlo, di solito si ha un FileInfo piuttosto che un string, che è una questione diversa.

Riesco a vedere il punto di vista dei colleghi: in un certo senso uno FileInfo è un modo "più pulito" di esprimere il parametro. Penso che string sia l'approccio più pragmatico però :)

Answer 2

Direi che dipende :) Molte operazioni di file statici sulla classe File consentono un numero di cose con il nome del file. L'astrazione di un file non è spesso utile in .NET Framework, quindi sono spinto a usare una stringa e a indicare nel nome dell'argomento cosa sia.

Answer 3

Penso che il nome del file sarà sufficiente se sta facendo la stessa cosa.

Answer 4

In genere passerei la stringa. Tuttavia, è possibile sovraccaricare il metodo per rendere tutti felici.

Answer 5

La differenza è principalmente che c'è un po 'di controllo in corso; il costruttore FileInfo esegue alcuni controlli per un parametro nullo o chiaramente non valido. Ci sono alcune altre cose che fa; prendere un FileInfo in pratica mette semplicemente l'onere di gestire le eccezioni dal costruttore FileInfo sul codice chiamante, al contrario del codice.

Ecco il riferimento MSDN per il costruttore FileInfo che mostra ciò che il costruttore può buttare:

http://msdn.microsoft.com/en-us/library/system.io.fileinfo.fileinfo.aspx

Answer 6

vorrei seguire la convenzione di usare Vapori. Ecco come vedo la maggior parte degli I/O eseguiti. Per me ha senso:

void Export(string s) 
{ 
    Stream fs = new FileStream(s); //think this is correct 
    Export(fs); 
} 
void Export(Stream s) 
{ 
    s.Write (...); 
    ... 
} 

Sono d'accordo, FileInfo non è mai stato così utile per me. attaccare con una stringa o utilizzare il flusso che può essere FileStream, MemoryStream, ecc.

Answer 7

Se si sta lavorando su un codice che coinvolge questi colleghi, vorrei utilizzare FileInfo.Non importa molto, ma scrivere il codice nel modo in cui altri si aspettano riduce la manutenzione, aumenta la coerenza e in generale rende le persone felici.

Mi preme sottolineare che non mi piace l'idea di utilizzare FileInfo per mettere l'onere degli assegni di validità sulla funzione di chiamata, come sottolineato da McWafflestix. Se qualcosa si rompe tra la funzione chiamante e la funzione che è stata chiamata, non verrà catturata. Non sarà necessariamente catturato se si utilizza una stringa ... ma almeno chiarisce dove può accadere il problema. E vorrete comunque cogliere tali eccezioni nel metodo chiamato. Sicuramente non aprirai il file e inizierai a leggere/scrivere finché non sarai nella funzione effettiva (se lo sei, FileInfo e string sono probabilmente la scelta sbagliata, ma Stream ha senso, come suggerisce TheSean).

Answer 8

Un FileInfo fa di più per mostrare l'intento del tipo di dati di una stringa. E questa è quasi sempre una buona cosa. Tuttavia, esistono sicuramente molti precedenti per il passaggio di un nome di file come stringa, inclusa la maggior parte dello stesso framework .NET. Un nome di file È una stringa. Presumibilmente, il chiamante dovrebbe utilizzare l'oggetto FileInfo per forzare il codice chiamante a convalidare il nome del file (ad esempio, gestire l'eccezione) anziché gravare con il superamento dell'eccezione.

Certamente, tra cui un overload del metodo eliminerebbe ogni dubbio, così a lungo come si sta convalidando il nome del file vengono passati.

Answer 9

Come al solito, dipende. In tutti tranne i casi più elementari, direi che usare FileInfo ti offre molti vantaggi senza quasi negativi. Il dogma OO rigoroso direbbe che le informazioni su un file (percorso, data di creazione, data di modifica, ecc.) Dovrebbero essere incapsulate all'interno di una classe come FileInfo. Ciò ti consentirà una maggiore flessibilità se in fondo hai bisogno di un comportamento più complesso. Se scrivi il tuo codice contro FileInfo, sarà quasi sempre più pulito e meno soggetto a errori se devi apportare modifiche.

Se non riesci a pensare a uno scenario in cui avresti bisogno di un comportamento più complesso, e ti lascerà davvero andare, vai avanti e usa solo una stringa.

Answer 10

1. La stringa non è PERCORSO. Quindi la stringa non è il modo migliore per rappresentare il percorso.
2. FileInfo non è anche un PERCORSO, semanticamente rappresenta FILE.

Quindi questo sarà meglio se MS fornirà oggetto Path :) o lo si può fare da soli, soprattutto se questo è il codice interno. In questo modo non avrai bisogno di controllare i tuoi argomenti PATH ogni volta che lavorerai con loro. Spesso ho molte strutture che rappresentano diverse punture, NonNullString, IdString (case insensitive), credo che ciò renda semplicemente il codice.