Parsing files to set data of an object - a design question

Question

I recently had to write some code which parsed a file to set data in an object. As there were several objects and corresponding files involved here, I decided to separate the parsing code out.

So I then had one class for parsing the files, CommandFileParser, and two classes per file/object type: one for the actual object itself and one for the possible commands that may be used to set the data in the object. e.g. VectorDrawing and VectorDrawingCommands. The latter's methods would be called by CommandFileParser using reflection as it found them in the input file, and applied data to the former.

But to me this seems like a really messy way of doing it. I ended up repeating loads of boilerplate code doing stuff like dataobject.value = value in all the of -Commands classes. And I don't like having an auxillary class per main data class just to set the data.

Can anyone suggest any ideas for cleaner and more appropriately OO ways of doing this?

Answer 1

"I ended up repeating loads of boilerplate code doing stuff like dataobject.value = value."

The assignment statement isn't really "boilerplate". It's the most important statement you have; the fact that there are many means you're doing lots of important things.

However, other "boilerplate" could be anything. Could you provide examples of the specific boilerplate you object to?

Answer 2

If all of your commands just involve direct assignments, perhaps you don't need the command objects. Can you directly do reflection on the objects themselves and get rid of the command objects entirely?

Another possibility is that you have two classes of commands: One is directly implemented by the object, e.g., simple property setting, and the other that is implemented by external command objects, e.g., for commands that need to do calculations or set multiple properties. You do the same reflection as before, but just check two objects.

BTW, I like the idea of using reflection to look for commands. It makes it incredibly easy to add new commands.

Answer 3

I don't know about VB.Net, but in all OO language with which I'm familiar, the normal approach is for a mutable object to contain the methods that set its own attributes' values, rather than putting that work into a second class.

Is there some reason why you wouldn't put the methods in your current VectorDrawingCommands class directly in VectorDrawing instead, and eliminate VectorDrawingCommands completely?

Answer 4

Maybe you want each Class to inherit the CommandFileParser instead of separating it out.

Answer 5

Why couldn't you just use reflection to set the values of the fields or properties directly and remove the entire concept of the -Commands classes?