class hierarchy design problem

[dgront]

There is my problem

* I have several (say: 5) classes : A, B, C. They rather hold some
data, but sometimes they do some simple operations on theirs data.

* The data can be stored is several various data formats: X, Y, Z, T, U
.... Several file formats can store data for a given class. Some file
formats hold more and some less information that is necessary to create
an instance of one of the classes: A B C

* The problem is to feed A, B or C with the data

My current solution:
- Each of the A, B, C classes has reading/writting method for each data
format:
A.readFromX()
A.readFromY()
A.readFromZ()
B.readFromX()
B.readFromY()
B.readFromZ()
.... (and writeTo.. methods)

Unfortunately, many of the formats do not handle all the necessary
data. For instance X has the half of the data and the rest is in Y. But
in the time of constructing object I don't have Y file. It can however
appear in the future.
So in my solution both X and Y readers create A and some of fields are
filled with some 'empty' contents (zeros, spaces, nulls...) If The
second file shows up, A.updateFromY() method is invoked.

In general my program works like that:
A.readFromX();
A.writeToZ(); // User can stop the program at this point - he will got
a Z file but some fields will be empty
for(; // Wait for user action. Also check if Y shows up
A.updateFromY()
A.writeToZ(); // all fields in Z are present

As you can see, creating a method:
A.readFromXY();
does not make sense, usually the two files: X and Y do not come
together

My solution works not that bad, but:
- there is an explosion of methods: three in each class for each data
format (readFrom, updateFrom, writeTo)

- file format specification is not fixed. Sometimes I face to a file
which my code fails to read. Then I have to trace all methods that
reads that file format in all the classes A, B, C.

- some of the fields of A may be defined both in X and Y. In general
the order:
A.readFromX();
A.updateFromY();
vs.
A.readFromY();
A.updateFromX();
makes a difference


Can anyone proppose a better solution? There is a bunch of my nevest
ideas:
- superclass that can read and write all the formats, like
metaparser.read(A,format_X)
is not a good choice for me - I want to keep A, B, C data private.

- at some point I used PostrgeSQL for this purpose. That was great, but
VERY inconvenient. I really need a single standalone program


Thanks in advance,
Dominik

 

[Oliver Wong]

There is my problem

* I have several (say: 5) classes : A, B, C. They rather hold some
data, but sometimes they do some simple operations on theirs data.

* The data can be stored is several various data formats: X, Y, Z, T, U
... Several file formats can store data for a given class. Some file
formats hold more and some less information that is necessary to create
an instance of one of the classes: A B C

* The problem is to feed A, B or C with the data

My current solution:
- Each of the A, B, C classes has reading/writting method for each data
format:
A.readFromX()
A.readFromY()
A.readFromZ()
B.readFromX()
B.readFromY()
B.readFromZ()
... (and writeTo.. methods)

Unfortunately, many of the formats do not handle all the necessary
data. For instance X has the half of the data and the rest is in Y. But
in the time of constructing object I don't have Y file. It can however
appear in the future.
So in my solution both X and Y readers create A and some of fields are
filled with some 'empty' contents (zeros, spaces, nulls...) If The
second file shows up, A.updateFromY() method is invoked.

In general my program works like that:
A.readFromX();
A.writeToZ(); // User can stop the program at this point - he will got
a Z file but some fields will be empty
for(; // Wait for user action. Also check if Y shows up
A.updateFromY()
A.writeToZ(); // all fields in Z are present

As you can see, creating a method:
A.readFromXY();
does not make sense, usually the two files: X and Y do not come
together

My solution works not that bad, but:
- there is an explosion of methods: three in each class for each data
format (readFrom, updateFrom, writeTo)

- file format specification is not fixed. Sometimes I face to a file
which my code fails to read. Then I have to trace all methods that
reads that file format in all the classes A, B, C.

- some of the fields of A may be defined both in X and Y. In general
the order:
A.readFromX();
A.updateFromY();
vs.
A.readFromY();
A.updateFromX();
makes a difference


Can anyone proppose a better solution? There is a bunch of my nevest
ideas:
- superclass that can read and write all the formats, like
metaparser.read(A,format_X)
is not a good choice for me - I want to keep A, B, C data private.

- at some point I used PostrgeSQL for this purpose. That was great, but
VERY inconvenient. I really need a single standalone program

You seem to be conflating the concepts of classes and objects, and of
files and file formats.

What is your program supposed to do? Convert from one file format to
another?

How about having one stage where you parse all the inputs, and build
model objects out of that. And then a second stage where you walk your model
data structure and emit all the data into files of the appropriate file
format?

- Oliver

 

[dgront]

What is your program supposed to do? Convert from one file format to
another?

Usually to convert, compute or check something from time to time

How about having one stage where you parse all the inputs, and build
model objects out of that. And then a second stage where you walk your model
data structure and emit all the data into files of the appropriate file
format?

The major problem is with the number of methods: now I have 7 object
types and 10 file formats. That makes 3 (read, update, write) x 10 x 7
methods. Each class for instance has a custom parser of X format that
reads only this data that the class wants to have

Yes, I can build 10 new classes, one for each file format, with a
single parser. But how to reduce the number of methods? With these 10
classes I still need the methods:
A.createFromX(), A.updateFromY()...

Dominik

 

[Oliver Wong]

Usually to convert, compute or check something from time to time




The major problem is with the number of methods: now I have 7 object
types and 10 file formats. That makes 3 (read, update, write) x 10 x 7
methods. Each class for instance has a custom parser of X format that
reads only this data that the class wants to have

Yes, I can build 10 new classes, one for each file format, with a
single parser. But how to reduce the number of methods? With these 10
classes I still need the methods:
A.createFromX(), A.updateFromY()...

How do you currently determine what file format(s) the input is encoded
in?

- Oliver

 

[dgront]

How do you currently determine what file format(s) the input is encoded

Some of the files have headers. But most of them were created in the
past times, when mostly FORTRAN was used. Therefore each file must have
an extension. Otherwise a user must explicitly define a format through
an option flag. If the format is wrong (wrong extension or a user made
a mistake), an exception is thrown.

Dominik

 

[Oliver Wong]

Some of the files have headers. But most of them were created in the
past times, when mostly FORTRAN was used. Therefore each file must have
an extension. Otherwise a user must explicitly define a format through
an option flag. If the format is wrong (wrong extension or a user made
a mistake), an exception is thrown.

Okay, and presumably the information you need to construct one
particular model object is spread across multiple files.

So I'd have a main driver class which organizes a list of files, and
maps them with their file formats. It would have 1 method: the static void
main method.

I'd then have a class to represent all the semantic data for each file
format, and thus create objects representing the contents of the files.
They'd have getters and setters.

I'd then have a translator class which takes in all these file objects
and converts them to model objects. It would have 1 method, taking in a
collection of file objects, and returning a collection of model objects.

I'd then have another translator class which takes in all these model
objects, and translate them back to file objects. Also 1 method, in the
reverse direction. Actually, this could be the same class as the previous.

I'd let the file objects know how to write themselves to disk. Each one
has 1 method.

That's 1 + N + 1 + M + 1 classes, where N is the number of file formats,
and M is the number of model classes.

1 + X + 1 + 1 + N methods, where X is the number of fields.

- Oliver