Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / August 2006

Tip: Looking for answers? Try searching our database.

class hierarchy design problem

Thread view: 
dgront - 02 Aug 2006 18:00 GMT
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 - 02 Aug 2006 18:04 GMT
> There is my problem
>
[quoted text clipped - 65 lines]
> - 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 - 02 Aug 2006 18:20 GMT
>     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 - 02 Aug 2006 18:37 GMT
>>     What is your program supposed to do? Convert from one file format to
>> another?
[quoted text clipped - 16 lines]
> 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 - 02 Aug 2006 21:18 GMT
>     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 - 02 Aug 2006 21:38 GMT
>>     How do you currently determine what file format(s) the input is
>> encoded
[quoted text clipped - 4 lines]
> 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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.