Design of input files reading when it comes to defaults/transformations

Posted by Stefano Borini on Programmers See other posts from Programmers or by Stefano Borini
Published on 2011-01-07T10:12:10Z Indexed on 2011/01/07 10:57 UTC
Read the original article Hit count: 344

Filed under:
|
|

Suppose you have an application that reads an input file, on a language that does not support the concept of None. The input is read, parsed, and the contents are stored on a structure for later use.

Now, in general you want to keep into account transformation of the data from the input, such as adding default values when not specified, or adding full path information to relative path specified in the input. There are two different strategies to achieve this.

The first strategy is to perform these transformations at input file reading time. In practice, you put all the intelligence into the input parser, and your application has no logic to deal with unexpected circumstances, such as an unspecified value. You lose the information of what was specified and what wasn't, but you gain in black-boxing the details. Your "running code" needs that information in any case and in a proper form, and is not concerned if it's the default or a user-specified information.

The second strategy is to have the file reader a real one-to-one mapper from the file to a memory-stored object, with no intelligent behavior. unspecified values are not filled (which may however be a problem in languages not supporting None) and data is stored verbatim from the file. The intelligence for recovery must now go into the "running code", which must check what was specified in the file, eventually fall back to a default, or modify the input properly before using it.

I would like to know your opinion on these two approaches, and in particular which one you found the most frequently implemented.

© Programmers or respective owner

Related posts about design

Related posts about opinion