回答:
それをサポートする言語で作業している場合は、ストリームを取得するSaveメソッドを提供します。これにより、ユーザーはどこにいてもデータを保存できます。
ファイルへの保存よりも書き込みに20秒長い時間がかかりますが、プログラマーには簡単に理解でき、呼び出し側では実際に何が発生するかが非常に明確になります。
それを記述した方法（入力を読み取り、別のファイルに出力するオブジェクト）は、奇妙に思えます。構築中にすべてを行うオブジェクトを構築する目的は何ですか？
このように呼びますか？
var stuff = DoStuff();
new SaveFileWeirdClass(stuff);
return;
SaveFileWeirdClassの合理的な実装については、それを作成するだけでは副作用はないと思います。ファイルの読み取り-結構です。ファイルを作成しますか？番号。
私にはそれはこのようにはっきりしているようです：
var stuff = new StuffReader(); //Better name needed...
string filePath = this.whatever;
using(Stream stream = new FileStream(filePath))
stuff.Save(stream);
クラスで行うことにこだわっている場合は、初期化中に作成してください。そのステップを遅らせると、2つの悪いことが起こります。1つ目は、出力を生成することを意図していない限り、最初にオブジェクトを作成しなかったであろう呼び出し側に、明示的なステップを追加することです。次に、クラスのコードがファイルを開いているかどうかを判断してその条件を処理する必要がある少なくとも2つのポイントを追加します。1つは出力を書き込むとき、もう1つは破棄するときに閉じるときです。前者は、書き込みのたびにそのチェックを行う必要があることを意味します。これは、大量のチェックを行う場合には無駄になる可能性があります。
個人的には、どちらも実行せず、呼び出し元に事前に開かれたファイルハンドルをコンストラクターに渡すことを選択します。クラス内にファイルを作成すると、アクセス許可の設定や、デバイスに書き込む場合はデバイス固有の初期化などのオプションを呼び出し元に与えることができなくなります。FooConverterファイルを操作し、作成の動作を行うクラスのバージョンが必要な場合は、それをでラップしFooFileConverterます。
明示的に。
将来のリリースや一般的ではないアーキテクチャーで機能しなくなる可能性がある巧妙な副作用規則に依存しないようにする必要があります。もちろん、ユーザーが上書きできるデフォルトのファイルを用意する必要があります。
明示的なメソッドの他の引数に加えて：コンストラクターで作業を行う場合、クラスのすべてのユーザーに、オブジェクトを作成するためだけに例外処理を強制する必要があります。これは、多くのボイラープレートコードにつながる可能性があります。
これに関する議論については、https：//stackoverflow.com/questions/6086334/is-it-good-practice-to-make-the-constructor-throw-an-exceptionを参照してください。