Re: suitable representation of data in OO programs.

Tom Forsmo wrote:


I have a question I would like some feedback on:

My basic problem here is that I need to create a configuration module,
that can parse both a configuration file and a configuration web page.
The input from the file can be a string or a stream but the input from a
web page is dependant on the framework used and needs to be converted.

So...

With regards to data beeing passed around in a program, such as
configuration data or web form data, I cant seem to make up my mind on
what representation of this data is best. I have seen people creating an
interface to represent the data in specialised data objects while others
just use HashMaps.

- The arguments for specialised data objects are that it is more
object oriented, and it gives benefits such as, single method call and
no casting of return data.

There are possibly two other benefits here. Firstly, if the arguments are
encapsulated by their own options, then they can be responsible for drawing
themselves (some arguments may be checkboxes, some may be radio buttons),
and so new argument types could be introduced without impacting the
existing types or their usage throughout the code. For more on this, see:
http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs110.html

Second, if each argument is encapsulated, then each one could be responsible
for validating whichever values to which it is being assigned, again
without impacting any other code.

- The arguments of HashMap is KISS.

- A negative consequence of specialised data objects is that if the
dataset changes, you have to change both the interface and the objects
implementing that interface.

I'm not sure what you mean by, "Dataset," here. Do you mean new types of
arguments? Do you mean, for example, that some arguments could now be
boolean, but next shipment might introduce integer arguments, then floats,
then strings?

If this is what you mean, then of course you are wise to consider possible
changes up-front; but will you configuration data really change that much?
It's difficult to think of configuration data that is not boolean,
multiple-choice, numbers or strings.

This creates more work than needed.
Additionally this kind of approach to designing an application just
feeds more complexity into the code.
- The negative consequenes of a HashMap approach is that one needs to
convert the data at every use point into the correct data type to be
able to use it.

I suppose it all depends on the use, so for configuration information I
would think a Properties object is the best.

I would not think that your choice of mechanism depends on use: I would
think it depends on how your your system can be resilient to the very
dataset changes that I interpretted you meant above. But I'm sure I'm
misunderstanding something because ...

But for web query data,
such as a web form, I am not sure which is easier, since you might
easily change the name of a forms field or add/remove a field.

.... I don't get this. Why would changing the name of a form (essentially
changing the name of an argument) be different whether using bespoke
argument classes or a Hashmap of (I presume) basic types?


Anybody have any thoughts?

--
..ed

www.EdmundKirwan.com - Home of The Fractal Class Composition

.