Design of an evaluator object for propagation and IO of results

Question

We are having a discussion about design. Keep into account this is fortran, so we can't be too smart. We have the following classes: Application, System, Calculator, CalculatorSimple, CalculatorPeriodic, Result.

Application is an application object which handles System objects. In order to compute information on the System object, the Application passes System to a Calculator, which returns a Result.

Inside Calculator there are two specialized classes CalculatorSimple, and CalculatorComplex, which act on System depending on information available on the system itself. Some Systems require CalculatorSimple. Others require CalculatorComplex. The decision happens inside Calculator, and the Result object may contain additional information if the CalculatorComplex was run. These additional info can be queried with methods on the Result object, to test if the information is present or not. This info is of small size.

To keep separation of roles, I want to keep this part unaware of input output. The Result object is received by the Application, and then the Application has the role of writing the data onto the file, according to what it finds on the Result object. A colleague instead proposes to pass the file to the Calculator object, and have it percolate through the chain so that stuff is written directly on the file.

The additional point is that we must have only one output file, so when the program runs in parallel, only the master node must write on the output file, which is identified via an absolute path and due to a limitation of our raw IO lib cannot be accessed by MPI slave processes.

We need an independent opinion. What would you do ?

Edit: thanks. I spread votes and awards as much as I could, as there's clearly not a correct answer, just a set of feedbacks.

Answer 1

I second Kerri's opinion - trying to pass the I/O object around will just mess with SRP of the system and obstruct the code's extendibility in the future. If you leave the logic out, you can even handle scenarios like outputing to multiple files/locations by constructing an observer pattern around this. (Actually I like that option even better if you can see growth in the near future - this way you are totally uncoupled).
Regarding restrictions on only one output file (I am assuming you meant you don't want concurrent writes), this should be restricted in the object that encapsulates the File. If you meant that you WANT to ensure that all processes write to one file only, again you can use a similar system with concurrency handling snugly sitting in this File object wrapper.

Answer 2

I prefer your solution, that of returning the result to the Application and letting it handle the file I/O. This de-couples your calculator from any file I/O, which means that you could theoretically use it in situations where you wouldn't be writing to a file, say, but updating the GUI or something else. If possible, my opinion is to stay as de-coupled as possible, coupling only when necessary.

But that's my opinion, and I've not written a word of Fortran in my life. I've done plenty of other OOP, though, and, in general, would do what I've already told you.

Answer 3

Returning results to the application would make this code much more maintainable than passing the file around. The calculation is independent of what is actually done with the result, and your code should reflect that. Writing to a file is basically a translation, I would abstract that into a file object, and let the Application object have the single responsibility to simply orchestrate between the related objects. This will have the added benefit of giving you a single place to look for problems when file writing is not producing the correct results. I'm not saying you should put the determination of who should write to the file in this new object, only the code that translates the result object to the data written to the file. It would really depend on more details about the system to determine how the single file writer issue should be handled.

Answer 4

Well, if you want to save the second half of the propagation (from the Calculator back to the Application), the Calculator could expect some sort of abstract Output it can write to, which you implement as you need.

The implementation of Output will be responsible for actual outputting (printing on screen, writing to file, dealing with concurrency etc.), the Application will wire up the Calculator with such an implementation and the Calculator will calculate and pass its result to said Output.