Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

B&S: Record and Contractor classes

Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I apologize in advance if this is really off the wall.

In my suncertify.db package, consider the two classes:
- (which implements the DB interface provided by Sun)

I have my Data class implemented such that it will work with any database that follows the schema provided by sun (magic cookie, field info, etc). So, for example, using my Data class with another database file that has a different number of fields, different field lengths, etc. would work fine. It deals with records as defined by the schema.

My DataAdapter class is more program specific. It deals with records as instances of contractors. (6 fields: Name, Location, Specialties, Size, Rate, Owner).

I decided to write a Contractor class that will wrap up a record and its record number, which can be sent to my ContractorTableModel class. It is fine to use this Contractor class in DataAdapter, but using it in Data would make my Data implementation program-specific, which i would like to avoid.

However, I would like to be able to wrap a record and it's record number in This isn't a problem: just create a class called Record. But since my Contractor class is a specific representation of a Record, then a Contractor IS A Record. No problem - my Contractor class simply extends Record.

So here's the problem: whenever I have a method that returns a Record/Collection of Records, it's located in my Data class. And whenever I have a method that returns a Contractor/Collection of Contractors, it's located in my DataAdapter class. But my DataAdapter class always calls the methods of my Data class, and NOT the other way around.

So, for example, consider the following methods:

Is this bad style? I already know that it's probably going a bit overboard, but is it bad style? I'm returning a Collection of Records from the method in the Data class, pulling the Records out, converting them to Contractors (which are Records), putting them in a new collection, and then returning the new Collection. I can't use a cast because the objects in the Collection from Data weren't origionally created as Contractors: they were created as Records.

Is this bad style, too much work, look good, or am I crazy?
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My 2 cents...

What you're doing is trying to create a Data Transfer Object that is more type-specific than a String[] of database fields (that's good IMO). I'm not really keen on the fact that you have a Record DTO in your Data implementation -- because the DBMain interface deals strictly with String[] return types. Ideally, that Record return type SHOULD be in DBMain... but it can't be because you're not allowed to change the provided interface.

On the other hand, your adapter class can use a Contractor-specific DTO return type... because you can create whatever interface you want, and use the implementation to wrap Data any way you see fit.

With java 1.5, generics make passing collections more palatable. I'd like to hear what most developer do with <= 1.4. I tend to convert collections to arrays of a specific type and pass them to the caller. It's more explicit, doesn't require the caller to cast, and looks better in interface definitions (ie: you can see (in code) the type of the objects being passed back).
Jared Chapman
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the reply.

I agree that using a Record class in Data would be nice, but not appropriate when all the required return types/arguments are String[]. How about making Contractor its own DTO without a superclass (other than Object, of course) and then having the following inner class in the Data class:

This record class would then only be used as a wrapper for a recNo, record between methods inside the Data class. For example, in my find(String[]) method, I call a private method in Data called getAllRecords(). This returns a collection of all the valid records in the database. Then, I iterate through the collection and remove all records that don't match the criteria. And finally, I return the record numbers of all records that aren't eliminated.

Doing it this way, I can transfer records around with their record numbers within the data class, and still preserve the required interface by returning Record.getData() rather than the record itself where appropriate.
[ October 30, 2004: Message edited by: Jared Chapman ]
Any sufficiently advanced technology will be used as a cat toy. And this tiny ad contains a very small cat:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic