При передаче имени файла методу я должен использовать FileInfo или простое имя файла?
Да: std::for_each .
void foo(int a) {
std::cout << a << "\n";
}
std::vector v;
...
std::for_each(v.begin(), v.end(), &foo);
10 ответов
Я бы обычно использовал строку - в большинстве случаев это проще. В противном случае вы, скорее всего, просто создадите новый FileInfo из строки в первую очередь.
Если вы создаете метод, вы всегда можете предоставить перегрузки, чтобы разрешить и то, и другое.
Конечно, , если вы знаете, что там, где вы собираетесь его назвать, обычно у вас есть FileInfo , а не строка , это другое дело.
Я могу понять точку зрения ваших коллег - в некотором смысле FileInfo - это более «чистый» способ выражения параметра. Я думаю, что string - более прагматичный подход :)
Обычно я передаю строку. Однако вы можете перегрузить метод, чтобы всех осчастливить.
Разница прежде всего в том, что выполняется небольшая проверка; конструктор FileInfo выполняет некоторую проверку на наличие нулевого или явно недопустимого параметра. Есть еще несколько вещей, которые он делает; взятие FileInfo в основном просто возлагает бремя обработки исключений из конструктора FileInfo на вызывающий код, а не на ваш код.
Вот ссылка MSDN на конструктор FileInfo, которая показывает, что может выдать конструктор:
http : //msdn.microsoft.com/en-us/library/system.io.fileinfo.fileinfo.aspx
Я бы сказал, это зависит от обстоятельств :) Многие операции со статическими файлами в классе File позволяют делать ряд вещей с именем файла. Абстракция файла не так часто бывает полезна в .NET Framework, поэтому я склонен использовать строку и указывать в имени аргумента, что это такое.
Думаю, имени файла будет достаточно, если он делает то же самое.
FileInfo делает больше, чтобы показать назначение типа данных, чем строка. И это почти всегда хорошо. Однако, безусловно, есть много прецедентов для передачи имени файла в виде строки, включая большую часть самой платформы .NET. Имя файла - это строка. Предположительно, вы бы попросили вызывающего абонента использовать объект FileInfo, чтобы заставить вызывающий код проверять имя файла (т. Е. Обрабатывать исключение), вместо того, чтобы обременять себя передачей исключения.
Конечно, включение перегрузки метода удалит все сомневаюсь, пока вы проверяете переданное имя файла.
Я бы следовал соглашению об использовании Steam. Так я вижу выполнение большинства операций ввода-вывода. Для меня это имеет смысл:
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 для ради возложения бремени проверок достоверности на вызывающую функцию, как указал McWafflestix. Если что-то прерывается между вызывающей функцией и вызванной функцией, это не будет обнаружено. Это не обязательно будет обнаружено, если вы используете строку ... но, по крайней мере, это проясняет, где может возникнуть проблема. И вы все равно захотите перехватывать такие исключения в вызываемом методе. Конечно, вы не собираетесь открывать файл и начинать чтение / запись, пока не
Как обычно, это зависит от обстоятельств. Я бы сказал, что во всех случаях, кроме самых простых, использование FileInfo дает много преимуществ при почти полном отсутствии минусов. Строгая догма объектно-ориентированного подхода гласит, что информация о файле (путь, дата создания, дата изменения и т. Д.) Должна быть инкапсулирована в такой класс, как FileInfo. Это даст вам больше гибкости, если в будущем вам понадобится более сложное поведение. Если вы пишете свой код для FileInfo, он почти всегда будет чище и менее подвержен ошибкам, если вам нужно внести изменения.
Если вы абсолютно не можете придумать сценарий, в котором вам потребуется более сложное поведение, и это собирается вас действительно сбить с толку, продолжайте и просто используйте строку.
- Строка не является ПУТЬ. Таким образом, строка - не лучший способ представления пути.
- FileInfo также не является PATH, семантически он представляет FILE.
Так что будет лучше, если MS предоставит объект Path :) или вы можете сделать это самостоятельно, особенно если это ваш внутренний код. Таким образом, вам не нужно будет проверять аргументы PATH каждый раз, когда вы будете с ними работать. У меня часто бывает много структур, которые представляют разные строки, NonNullString, IdString (без учета регистра), я считаю, что это упрощает код.