Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm creating an object whose sole purpose is to read in a file of one format and create another of a different format.

Is it best to create the output file implicitly during object initialization or to have a public method that gives the user the choice when this file will be created?

share|improve this question
up vote 12 down vote accepted

If you are working in a language that supports it, I'd provide a Save method that takes a Stream. That way, the user can save the data whereever he or she wants.

It takes 20 seconds longer to write than saving just to a file, but it is easily understood by a programmer, and at the calling site it is very clear what actually happens.

The way you described it (an object that reads input, and outputs to another file) otherwise seems weird. What is the purpose of constructing an object that does everything during construction?

Would you call it this way?

var stuff = DoStuff();
new SaveFileWeirdClass(stuff);

For any reasonable implementation of SaveFileWeirdClass I would expect no side effects from just creating it. Reading a file - fine. Creating a file? No.

To me it seems clearer this way:

var stuff = new StuffReader(); //Better name needed...
string filePath = this.whatever;

using(Stream stream = new FileStream(filePath))
share|improve this answer
This is good. Another, similar, option is to just implement an object that implements whatever stream base the application has and treat it as you would any other stream. – Steve Evers Oct 24 '11 at 13:07

If you're bent on doing it in the class, create it during initialization. Delaying that step does two bad things: First, it adds an extra, explicit step for the caller, who wouldn't have created the object in the first place unless they intended to use it to produce output. Second, it adds at least two points where code in the class has to make a decision about whether or not the file is open and handle that condition: once when you go to write output and once during destruction when you go to close it. The former means you have to make that check during every write, which could be wasteful if you're doing a lot of them.

Personally, I would do neither and opt for making the caller pass pre-opened file handles to the constructor. Creating the file inside the class precludes giving the callers the options to do things like setting permissions or, if writing to a device, doing device-specific initialization. If you want to have a version of your FooConverter class that operates on files and does the creation grunt work, wrap it in a FooFileConverter.

share|improve this answer


You want to make sure that you do not rely on clever side effect rules that may either break in future releases or on uncommon architectures. Of course, you should have a default file that the user can overwrite should they choose to.

share|improve this answer

In addition to the other arguments for an explicit method: If you do the work in the constructor, then you force every user of your class to do exception handling just for creating the object. This can lead to lots of boilerplate code.

See for a discussion around that.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.