Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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);
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.
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.
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 https://stackoverflow.com/questions/6086334/is-it-good-practice-to-make-the-constructor-throw-an-exception for a discussion around that.
