• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Comparing analogous objects in several collections

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I have coded myself into a corner, and I am no longer certain how to approach this. I am working on a program which reads meteorological data from a flat file. I have given the data the following structure:

Each meteorological station is an object: Station.
A SystemData object holds a HashMap of Station Objects.
Each Station has a collection of MonthData objects.
Each MonthData object has a collection of DayData objects.

For the most part, I simply need to work on the data of a single Station at a time, or for several consecutive Stations and then compare the results, so this structure has not given me any trouble.

In addition, though, I need to do a month-by-month comparison of precipitation (which is an attribute of the DayData objects) and separate the values based on the altitude of each Station (recorded in the Station object).

Logically, I just need to iterate through the collections in some fashion, like so:



The problem is that with this approach I need to pull a number out of a hat in order to make the first *for* loop. I can't say:



...because my HashMaps with MonthData are inside Station objects, not to mention that they could be of variable length (ok, so technically they shouldn't have variable lengths, but I'm not the one pulling together the flat files, I'm just supposed to read from them).

Right now the only roads out of this that I see are incredibly murky and roundabout, looping through the Stations for a single month, doing calculations, looping through again for the next month, etc, as many times as necessary, or looping through the Stations once and calculating data for each of the months, and putting the results in separate variables depending on the month. Or looping through the stations to find out what the largest collection of MonthData objects is and use that to iterate (skipping null references when necessary).

Would someone please help me sort out my thinking so I can find a way out of this mess in a less kludgy way than this? If you require more clues to how I've been thinking about this, I will be happy to provide them. At this point I am not sure what is necessary and what is just confusing.

Kind regards,
Jane
[ November 01, 2006: Message edited by: Jane Delphiki ]
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Jane,

Welcome to JavaRanch!

I don't think the second approach (iterating over stations, accumulating month data) is kludgy at all. Sometimes that's what you have to do. I could go into a long discussion of object-oriented data modeling vs a relational model as represented by database tables; sometimes, as here, a relational model just makes sense. But nonetheless, I wouldn't think of using an auxilliary data structure as a bad thing.
 
Jane Delphiki
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for getting back to me on this!

I will go with the second approach. All the rest of the operations I need to perform are such that an object oriented approach makes sense, there are only a couple of comparisons that need some extra attention.

Thanks for the warm welcome, as well! Nice to drop by a friendly place.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic