Должен ли я использовать FileInfo или простое имя файла при передаче имени файла методу? - PullRequest
Новая
       169

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

12 голосов
/ 27 мая 2009

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

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

  • void Export (FileInfo fileInfo)

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

  • void Export (строка fileName)

Спасибо!

Ответы [ 10 ]

17 голосов
/ 27 мая 2009

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

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

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

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

6 голосов
/ 27 мая 2009

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

5 голосов
/ 27 мая 2009

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

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

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

3 голосов
/ 27 мая 2009

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

2 голосов
/ 27 мая 2009

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

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

2 голосов
/ 27 мая 2009

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

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

1 голос
/ 30 мая 2009
  1. Строка не является PATH. Так что строка не лучший способ представить путь.
  2. FileInfo также не является PATH, семантически он представляет FILE.

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

1 голос
/ 27 мая 2009

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

0 голосов
/ 27 мая 2009

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

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

0 голосов
/ 27 мая 2009

Я бы следовал соглашению об использовании 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 и т. д.

...