Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

4 Answers 4

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);
return;

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))
    stuff.Save(stream);
share|improve this answer
1  
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

Explicitly.

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

Neither. The best design is to create the file when and where it will be used. This will be in differing places depending upon your design and usage. Depending upon your design, your object might not even really be an object, it may be a static class, that takes a file name, or path, or stream, or counter.

So, there's no one right choice, but there are some right questions: does this need to be a file, does it need to exist at this time? Can my process fail between now and when I will first write to this file?

share|improve this answer

Your Answer

 
discard

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.