Object Oriented Design approach to a conversion app

views:

101

answers:

+1 Q:

Object Oriented Design approach to a conversion app

I think i might be being blinded by the way I've learned OO principles. Its always taught in the manner of tangible object is a descendant of another tangible object. Anyway...

I'm trying to work out an OO approach to a conversion utility, basically it will read a text file and based on the first word(s) on the line it will go off and translate / do whatever corresponds. Would this be a case of each command is a new object or...

Its probably a simple answer but I'm struggling

I would not get too caught up in OO design for something like this. OO principles should be used only if they are obvious and help you with reuse. That might not be the case here. Also, this does not sound like a large app. The pitfall people fall into is making way too many classes just to get a little bit of reuse. This quickly makes things unmanageable. Just do it the old-fashioned way and if something jumps out at you where inheritance can help for example, then use it.

Francis Upton 2009-12-13 21:32:52

Thats absoultely untrue. Designing this in an OO approach allows for the application to be extended later on with new keywords/tokens and it allows for complete separation of functionality from interface.

monksy 2009-12-13 21:40:51

OOP is not only about reuse, it's also about separating what varies so that parts can very independently of each other. This is a great example of parts that vary independently of each other: the format of the input and the format of the output. So your claim that OOP makes "things" unmanageable strikes me as being a bit naive. Having all of the code responsibilities lumped in a huge transaction script will definitely be unmanageable.

RibaldEddie 2009-12-13 21:43:44

Perhaps you could take a closer look at what I have written, I don't think what I'm saying contradicts what you say. It's just that people tend to put in too much extensibility sometimes and it makes things overly complicated.

Francis Upton 2009-12-13 21:45:18

@RibaldWEddie, I did not make the claim that you suggest. I was responding the OPs comment about perhaps having a class for each command.

Francis Upton 2009-12-13 21:47:38

@Francis ... I did read what you wrote.. small applications (espically with this type of feature) become large quite quickly.

monksy 2009-12-13 21:53:27

@steven, they may or may not get large, and as they do, and that can be the point to consider adding more classes and hierarchy, and to refactor as necessary. I guess I'm with the "simplest thing that can possibly work" school (as long as it's minimum code and no duplication).

Francis Upton 2009-12-13 22:02:14

+2 A:

I did this once for a database conversion application. I had import plugins (classes) that read data into a common model. Then the export plugins (classes) read the common model and wrote it out to a database. In my case, this was a .NET application, so I used MEF to split the importers and exporters into different assemblies. Customers could plug in whatever importers and exporters they needed, or could even write their own if they wanted to.

David Brown 2009-12-13 21:32:56

+2 A:

Take a look at the Interpreter, and the Factory Method patterns.

monksy 2009-12-13 21:33:27

ansaurus

tags:

views:

answers:

Object Oriented Design approach to a conversion app

related questions