При передаче имени файла методу следует использовать FileInfo или простое имя файла?

Ну, в названии говорится все. При передаче имени файла методу следует использовать объект FileInfo или простое имя файла (строка)? Почему я должен отдать предпочтение другому?

Некоторые из моих коллег любят писать метод следующим образом:

  • void Export (FileInfo fileInfo)

Это лучше, чем:

  • void Export (string fileName)

Спасибо!

Ответ 1

Обычно я просто использовал string - в большинстве случаев это проще. В противном случае вы, вероятно, просто создадите новый FileInfo из строки в первую очередь.

Если вы создаете метод, вы всегда можете предоставить перегрузки, чтобы разрешить оба.

Конечно, если вы знаете, что там, где вы собираетесь его называть, у вас обычно есть FileInfo, а не string, что другое дело.

Я вижу точку зрения ваших коллег - в некотором смысле FileInfo является "более чистым" способом выражения параметра. Я думаю, что string - более прагматичный подход:)

Ответ 2

Обычно я передавал строку. Однако вы можете перегрузить метод, чтобы все были счастливы.

Ответ 3

Разница заключается прежде всего в том, что происходит немного проверки; конструктор FileInfo выполняет некоторую проверку нулевого или явно недопустимого параметра. Есть еще несколько вещей, которые он делает; взятие FileInfo в основном просто ставит бремя обработки исключений из конструктора FileInfo в вызывающем коде, в отличие от вашего кода.

Здесь ссылка MSDN для конструктора FileInfo, которая показывает, что может создать конструктор:

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

Ответ 4

Я бы сказал, что это зависит:) Многие статические файловые операции над файлом класса позволяют использовать несколько файлов с именем файла. Абстракция файла не так часто бывает полезной в .NET Framework, поэтому я предвзято отношусь к использованию строки и обозначая в имени аргумента, что это такое.

Ответ 5

Если вы работаете над кодом с участием этих коллег, я бы использовал FileInfo. Это действительно не имеет большого значения, но написание кода так, как другие ожидают, что он уменьшает поддержку, повышает согласованность и, как правило, делает людей счастливыми.

Я укажу, что мне не нравится идея использования FileInfo для того, чтобы наложить на них ответственность за достоверность вызывающей функции, как указано McWafflestix. Если что-то сломается между вызывающей функцией и вызываемой функцией, ее не поймают. Это не обязательно будет поймано, если вы используете строку... но по крайней мере она дает понять, где может возникнуть проблема. И вы захотите поймать такие исключения в вызываемом методе в любом случае. Конечно, вы не собираетесь открывать файл и начинать чтение/запись до тех пор, пока не будете в действительной функции (если вы так, FileInfo и строка, вероятно, являются неправильным выбором, но Stream имеет смысл, как предлагает TheSean).

Ответ 6

FileInfo делает больше, чтобы показать намерение типа данных, чем строку. И это почти всегда хорошо. Тем не менее, существует множество прецедентов для передачи имени файла в виде строки, в том числе самой платформы .NET. Имя файла - строка. Предположительно, вы должны использовать вызывающий объект FileInfo, чтобы заставить вызывающий код проверять имя файла (т.е. Обрабатывать исключение), а не обременять себя возвратом исключения.

Конечно, в том числе перегрузка метода удалит все сомнения, пока вы проверяете переданное имя файла.

Ответ 7

Я думаю, что имя файла будет достаточным, если оно будет делать то же самое.

Ответ 8

  • Строка не PATH. Так что строка - это не лучший способ представления пути.
  • FileInfo также не является PATH, семантически он представляет FILE.

Итак, это будет лучше, если MS предоставит объект Path:) или вы можете сделать это самостоятельно, особенно если это ваш внутренний код. Таким образом, вам не нужно проверять свои аргументы PATH каждый раз, когда вы будете работать с ними. У меня часто есть много структур, которые представляют разные укусы, NonNullString, IdString (без учета регистра), я считаю, что это делает код просто.

Ответ 9

Я следовал соглашению об использовании Steams. Вот как я вижу большинство операций ввода-вывода. Это имеет смысл для меня:

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

Я согласен, FileInfo никогда не был так полезен для меня. придерживаться строки или использовать поток, который может быть FileStream, MemoryStream и т.д.

Ответ 10

Как обычно, это зависит. Во всех, кроме самых основных случаях, я бы сказал, что использование FileInfo дает вам много преимуществ без почти никаких негативов. Строгая догма ОО говорит, что информация о файле (путь, дата создания, измененная дата и т.д.) Должна быть инкапсулирована в класс, такой как FileInfo. Это позволит вам проявлять большую гибкость, если по дороге вам потребуется более сложное поведение. Если вы напишете свой код против FileInfo, он почти всегда будет более чистым и менее подверженным ошибкам, если вам нужно внести изменения.

Если вы абсолютно не можете думать о сценарии, где вам нужно более сложное поведение, и он действительно вас отбросит, идите и просто используйте строку.