B&S: Record and Contractor classes

[Jared Chapman]

I apologize in advance if this is really off the wall.

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

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 Data.java. 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:

//in Data.java:
public Collection getRecords(){...} //returns a Collection of Records
 
//in DataAdapter.java:
//NOTE: want to return a collection of Contractors, not Records
public Collection getContractors{
 
    ArrayList contractors = new ArrayList();
 
    ArrayList records = (ArrayList)db.getRecords();
    Iterator it = records.iterator();
 
    while(it.hasNext()){
        Record r = (Record)it.next();
        contractors.add(new Contractor(r.getRecNo(), r.toStringArray()));
    }
    return contractors;
}

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?

[Robert Hayes]

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]

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:

class Record{
  private int recNo;
  private String[] data;
 
  public Record(int recNo, String[] data){
    this.recNo = recNo;
    this.data = data;
  }
 
  public int getRecNo(){
    return recNo;
  }
 
  public String[] getData(){
    return data;
  }
 
}

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 ]