Ну, в названии говорится все. При передаче имени файла методу следует использовать объект FileInfo или простое имя файла (строка)? Почему я должен отдать предпочтение другому?
Некоторые из моих коллег любят писать метод следующим образом:
Это лучше, чем:
Спасибо!
Обычно я просто использовал string - в большинстве случаев это проще. В противном случае вы, вероятно, просто создадите новый FileInfo из строки в первую очередь.
Если вы создаете метод, вы всегда можете предоставить перегрузки, чтобы разрешить оба.
Конечно, если вы знаете, что там, где вы собираетесь его называть, у вас обычно есть FileInfo, а не string, что другое дело.
Я вижу точку зрения ваших коллег - в некотором смысле FileInfo является "более чистым" способом выражения параметра. Я думаю, что string - более прагматичный подход:)
Обычно я передавал строку. Однако вы можете перегрузить метод, чтобы все были счастливы.
Разница заключается прежде всего в том, что происходит немного проверки; конструктор FileInfo выполняет некоторую проверку нулевого или явно недопустимого параметра. Есть еще несколько вещей, которые он делает; взятие FileInfo в основном просто ставит бремя обработки исключений из конструктора FileInfo в вызывающем коде, в отличие от вашего кода.
Здесь ссылка MSDN для конструктора FileInfo, которая показывает, что может создать конструктор:
http://msdn.microsoft.com/en-us/library/system.io.fileinfo.fileinfo.aspx
Я бы сказал, что это зависит:) Многие статические файловые операции над файлом класса позволяют использовать несколько файлов с именем файла. Абстракция файла не так часто бывает полезной в .NET Framework, поэтому я предвзято отношусь к использованию строки и обозначая в имени аргумента, что это такое.
Если вы работаете над кодом с участием этих коллег, я бы использовал FileInfo. Это действительно не имеет большого значения, но написание кода так, как другие ожидают, что он уменьшает поддержку, повышает согласованность и, как правило, делает людей счастливыми.
Я укажу, что мне не нравится идея использования FileInfo для того, чтобы наложить на них ответственность за достоверность вызывающей функции, как указано McWafflestix. Если что-то сломается между вызывающей функцией и вызываемой функцией, ее не поймают. Это не обязательно будет поймано, если вы используете строку... но по крайней мере она дает понять, где может возникнуть проблема. И вы захотите поймать такие исключения в вызываемом методе в любом случае. Конечно, вы не собираетесь открывать файл и начинать чтение/запись до тех пор, пока не будете в действительной функции (если вы так, FileInfo и строка, вероятно, являются неправильным выбором, но Stream имеет смысл, как предлагает TheSean).
FileInfo делает больше, чтобы показать намерение типа данных, чем строку. И это почти всегда хорошо. Тем не менее, существует множество прецедентов для передачи имени файла в виде строки, в том числе самой платформы .NET. Имя файла - строка. Предположительно, вы должны использовать вызывающий объект FileInfo, чтобы заставить вызывающий код проверять имя файла (т.е. Обрабатывать исключение), а не обременять себя возвратом исключения.
Конечно, в том числе перегрузка метода удалит все сомнения, пока вы проверяете переданное имя файла.
Я думаю, что имя файла будет достаточным, если оно будет делать то же самое.
Итак, это будет лучше, если MS предоставит объект Path:) или вы можете сделать это самостоятельно, особенно если это ваш внутренний код. Таким образом, вам не нужно проверять свои аргументы PATH каждый раз, когда вы будете работать с ними. У меня часто есть много структур, которые представляют разные укусы, NonNullString, IdString (без учета регистра), я считаю, что это делает код просто.
Я следовал соглашению об использовании 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 и т.д.
Как обычно, это зависит. Во всех, кроме самых основных случаях, я бы сказал, что использование FileInfo дает вам много преимуществ без почти никаких негативов. Строгая догма ОО говорит, что информация о файле (путь, дата создания, измененная дата и т.д.) Должна быть инкапсулирована в класс, такой как FileInfo. Это позволит вам проявлять большую гибкость, если по дороге вам потребуется более сложное поведение. Если вы напишете свой код против FileInfo, он почти всегда будет более чистым и менее подверженным ошибкам, если вам нужно внести изменения.
Если вы абсолютно не можете думать о сценарии, где вам нужно более сложное поведение, и он действительно вас отбросит, идите и просто используйте строку.