При передаче имени файла методу следует использовать 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, он почти всегда будет более чистым и менее подверженным ошибкам, если вам нужно внести изменения.
Если вы абсолютно не можете думать о сценарии, где вам нужно более сложное поведение, и он действительно вас отбросит, идите и просто используйте строку.