I wouldn't. I've found constructors that do I/O to be unclear in most situations where I've seen them.//I would make this a constructor for Student instead.
I wouldn't. I've found constructors that do I/O to be unclear in most situations where I've seen them.//I would make this a constructor for Student instead.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Just a question about that, would you still say that if the constructor took a stream object as an input ? ....(along with overloading, to provide another interface)....Originally Posted by CornedBee
Yes. A constructor taking a stream does not indicate what kind of interaction it has with the stream. Will it interactively read a record from the user, along with input validation and prompting the user for correction of bad input? (In such a case you also need an output stream for such prompts.) Or will it read the record of a fixed format from a file, where throwing an exception is an acceptable response to bad input? The latter case is one where I would find a constructor taking a stream more appropriate, though it still leaves something to be desired in terms of flexibility, since the constructor can only support one format.
In all such cases, I would consider free functions a better choice for doing I/O. This includes the print() function, by the way.
When you put interactive I/O into your domain objects (Student clearly is of that kind) you saddle them with a lot of concerns. Input validation is just one of them - having user interaction also means localization, for example. Then there's the matter of choice of user interface. These things do not, of course, matter for toy programs, but can quickly become very relevant when programs grow and mature.
This is, in essence, what the model-view-controller (MVC) pattern is about: separating the model (your domain objects) from functionality specific to one kind of user interface. If Student were to have a print() function to print its contents to the console, you have mingled the view (console) with the model (Student). What will you do with that print() function when you want to convert the program to have a GUI instead of being a console program? Where will you put the functions to display a Student in the GUI? The answer should not be a modification to Student.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
