How best to handle hundreds of similar objects?

Question

Hi. I'm a relative newcomer to Java. I've been working on an application that involves a table of data. Each column in the table represents a different type of data. The data can be numeric, dates, Strings, etc. If I were to create an interface describing the charcteristics that each implementation of a column should have, it would be something like:
getTitle();
getDataType();
getDefinition; //some columns will require explanation (maybe via tooltip or dialog box)
getValue; //could be simple as pulling a value from a database or could be complicated code
getDependencies; //identify what other columns may be required to be present in order to calculate getValue();
getSettingsDialog(); //return JDialog with a custom control panel for the particular column (may include formatting, calculation parameters, etc.)
etc.
etc.
So, the quesiton I'm struggling with is that if in the long run there may be hundreds of unique columns, is it better to create a separate class for each column, or create one class and just parameterize everything. It seemed odd to me to create hundreds of similar classes, so I started out creating one class and creating new instances for each column needed. But, if you do that, how do you store stuff like the code needed for certain methods? For example, the calculations in getValue() could involve lengthy code. Do I just store all of the various getValue() code in one big static class that the column instance would look up or call? Or should I just switch to creating a new class for each column I need (all obviously deriving from the same abstract class/interface)?
Sorry if this isn't clear. I have been reading through various OOPS and design pattern books, but haven't found anything that clears this up definitively. Thanks.

Answer 1

Bob.B wrote:
Some of the data comes from a database, but a lot of it is then derived from that data. There really can be hundreds of columns. The data I'm dealing with is kind of esoteric, so I'll try to describe the situation with a more common set of data. Imagine you were lucky enough to own McDonalds (the whole company) and you wanted a view of how all of the franchises were doing (the franchises would be the rows in the table). Each franchise will have hundreds of characteristics about it stored in some database (e.g. owner, address, city, state, date opened, total hamburger sales each day, total milkshake sales each day, etc. etc.). The application is essentially a treetable that allows the user to 1) pull whatever franchises he wants based on user criteria, 2) group and subtotal the franchise data on any available field (e.g. group and subtotal franchise data by city), and 3) choose what data (i.e. columns) is displayed.
"Treetable" is a GUI item. You probably shouldn't be pulling the entire dataset, but rather pulling it at once.
The data structure can drive the GUI but it probably shouldn't be the sole driving factor. Unless the only goal is to drive a reporting engine. See below.
If the columns merely pulled the data as is from the database, it would be pretty straightforward to just have one column class that knows which db field to pull and then display. But, imagine that there are many more potential columns that get a little bit more complicated. For example, there may be standard metrics that are not directly stored in the database because they can be derived. For example, hamburger sales per store, hamburger sales per day for each day of the week, the ratio of hamburger sales to milkshake sales, etc. Anyway, with the data I'm dealing with, these calculations can get quite complex and there are actually many, many standard metrics that the user would want to see. There are also aspects of the data that the user would want to control on the fly (i.e. have access to column by column settings).
Presumably you are carefully controlling the data calculation. If it pulls a number today for last weeks data it must be able to pull that same number next year even if how the result is calculated changes later this year.
So, I think it makes sense for the columns to each be separate objects. I started by having one column class, and when I needed a complicated getValue() function in it, I just stored the calculations in one giant static class that has all the various calculations, and I access the appropriate calculation in that class with a switch statement. I just wasn't sure if this was the most efficient way to do it. It would be easier for me to just have a separate class for each column (all with the same interface), but I didn't know what the overhead in Java was to have hundreds of distinct classes.
Sounds like a report to me. One layer encapsulates real data. Another layer encapsulates reporting. Values that appear on reports are either data or they are calculated from the data. Notice the the report layer, not the data layer, does the calculation.
Keep in mind that the calculations themselves might be data driven but by their own data layer. This can include parameters of the calculation, like sales tax for the given period, or the calculation itself (for instance by keeping the algorithm as a java class in the database.)
Also note that reporting (which includes more that printed reports) is not new and there are commercial and freeware frameworks for it.