まあ、タイトルはそれをすべて言います。ファイル名をメソッドに渡す場合、FileInfo オブジェクトまたはプレーン ファイル名 (文字列) を使用する必要がありますか? なぜ私はどちらかを好むのですか?
私の同僚の中には、次のようなメソッドを書くのが好きな人もいます:
- void Export(FileInfo fileInfo)
それはより良いですか:
- void エクスポート (文字列ファイル名)
ありがとう!
私は通常 a を使用しますstring
- ほとんどの場合、それはより簡単です。FileInfo
それ以外の場合は、最初に文字列から新しいものを作成する可能性があります。
メソッドを作成している場合は、常に両方を許可するオーバーロードを提供できます。
もちろん、それをどこで呼び出すつもりであるかがわかっている場合、通常はaFileInfo
ではなく aを使用しますがstring
、それは別の問題です。
あなたの同僚の見解はわかります。ある意味では、aFileInfo
はパラメータを表現する「よりクリーンな」方法です。私string
はより実用的なアプローチだと思います:)
通常、文字列を渡します。ただし、メソッドをオーバーロードして、全員を満足させることができます。
主な違いは、チェックが少し行われていることです。FileInfo コンストラクターは、null または明らかに無効なパラメーターをチェックします。他にもいくつかの機能があります。FileInfo を取得すると、基本的に、コードではなく、呼び出し元のコードで FileInfo コンストラクターからの例外を処理する責任が生じるだけです。
コンストラクターがスローできるものを示す FileInfo コンストラクターの MSDN リファレンスを次に示します。
http://msdn.microsoft.com/en-us/library/system.io.fileinfo.fileinfo.aspx
私はそれが依存していると言うでしょう:) Fileクラスの多くの静的ファイル操作は、ファイル名で多くのことを可能にします。File の抽象化は .NET Framework ではあまり役に立ちません。そのため、私は文字列を使用し、それが何であるかを引数名で示すことに偏っています。
これらの同僚が関与するコードに取り組んでいる場合は、FileInfo を使用します。実際には大した問題ではありませんが、他の人が期待する方法でコードを書くことは、保守性を低下させ、一貫性を高め、一般的に人々を幸せにします。
FileInfo
McWafflestix が指摘したように、呼び出し元の関数の有効性をチェックする責任を負わせるために使用するという考えが嫌いであることを指摘します。呼び出し元の関数と呼び出された関数の間で何かが壊れた場合、それはキャッチされません。文字列を使用しても必ずしもキャッチされるとは限りません...しかし、少なくとも問題が発生する可能性がある場所を明確にします。とにかく、呼び出されたメソッドでそのような例外をキャッチする必要があります。確かに、実際の関数に入るまで、ファイルを開いて読み取り/書き込みを開始することはありません (そうであれば、FileInfo と文字列はおそらくどちらも間違った選択ですが、TheSean が示唆するように Stream は理にかなっています)。
MSがPathオブジェクトを提供する場合、これはより良いでしょう:)または、特にこれが内部コードである場合は、自分で作成できます。このようにして、PATH 引数を使用するたびに PATH 引数を確認する必要がなくなります。私は多くの場合、さまざまな文字列、NonNullString、IdString (大文字と小文字を区別しない) を表す多くの構造体を持っています。これにより、コードが単純になると思います。
同じことをしているならファイル名で十分だと思います。
Steam を使用する規則に従います。これは、ほとんどの I/O が実行される方法です。それは私には理にかなっています:
void Export(string s)
{
Stream fs = new FileStream(s); //think this is correct
Export(fs);
}
void Export(Stream s)
{
s.Write ( ... );
...
}
確かに、FileInfo は私にとってこれほど便利なものではありませんでした。文字列に固執するか、FileStream、MemoryStream などのストリームを使用します。