OO question: creating object of unknown type 3

[NathanR]

Hi,

I have a question about a programming problem that I encounter for the first time; I think it comes up only with user/database interaction. I have a solution that will "work", but it's so ugly! If someone please could tell me how to do this properly...

I read an existing database using JDBC. The tables in the database correspond exactly to the objects I'd like to have in Java, and so to create an object, I send the primary key to the object constructor, which makes the sql call and initializes all the private members.

This works perfectly except for one object. I'll use the time-honored Vehicle analogy for simplicity.

In the database I have one Vehicle table with the common elements, one element containing the type of vehicle, and a table for each type type of vehicle with the elements specific to each type. The tables all share the same primary key, so for each key there is one record in the Vehicle table and one record in only one of the sub-tables.

In Java, I would like a Vehicle class extended by a subclass for each vehicle. My problem is, how to read in the elements?

When I call the Vehicle constructor with the primary key, I'll have no idea which specific kind of Vehicle should be created, and as far as I can see there's no way of a constructor deciding that the new object should actually be on instance of a subclass?

Next thought is using an external method that makes a db call, determines the type of vehicle, and creates an object of appropriate type that then makes a second identical db call . . . ugly!

So I thought of a Vehicle class containing a VehicleSpecific object, so that the Vehicle constructor decides on the kind of VehicleSpecific object and creates a instance of the class of that name (reflection is cool). But I won't be able to access the common Vehicle variables from the VehicleSpecific methods without some kind of pointer toward the including object, right? Seems dirty and I don't know how.

Next step is googling and FAQ searching, but I can't find anything. Next step is asking for help...

 

[byam]

Looking at your database design, Vehical should be an abstract class and only instantiate by it subclass.

What I would do is have a manager class to retireve the vehicle from database.

Public VehicleManager {

// assuming the primary key is an integer
public Vehicle getVehicle(int id) {
/*
1. do sql seach in vehicle table for given id
2. from the result, you know the vehicle type and what sub-class to instantiate.
3. now can instantiate appropiate vehicle sub-class
*/
}

}

 

[NathanR]

Hmm yes. "Manager" rings a Pointy-Haired bell as something "pretty" to do

I thought of this as

"external method that makes a db call, determines the type of vehicle, and creates an object of appropriate type that then makes a second identical db call . . . ugly!"

So I have three options,

1) make two different db calls (rather not)

2) pass the object resulting from the db call to the subclass constructor (error waiting to happen when fields are changed?)

3) let VehicleManager do the updating of the common fields, either by

3.1) setting them to protected instead of private, or
3.2) with some kind of friend construct that I don't think Java has.

I think I'll go with 2), as it is changing db fields will be a really big operation anyway.

HAND and thanks for giving me peace of mind

 

[hologram]

The two approaches have something in common : You need to know the type of vehicle before calling the constructor of the specific type.
NathanR uses a constructor of Vehicle to do this.
Byam uses a VehicleManager to do this.
I prefer the second method. [ Vehicle can also be an interface ].

Maybe it could be a good idea to create/get all objects via a "manager". It is even possible to have 1 manager for all your tables. If you pass the id or the record and the name of your class and table to the "manager", then the manager can get the constructors for the class...

Contructor constructor = theClass.getConstructor(...);
Object object = constructor.newInstance(...);

First get the info from the database and then call the constructor and fill the object. In this way there is no database code in your constructor.

If you want to search the internet try "object relational mapping". You can also have a look at JDO
and hibernate

http://www.hibernate.org/

but since you have everything already working you better stick to your own code.

 

[byam]

I agree with hologram. Hibernate is a very good persistent framework. I've tried that, it's very cool. There are tools that can generate all the mapping files and data objects class from a database. So, once you have a database setup, you don't really need write too much code.

 

[sedj]

My two cents ...

In the past, I wrote an "Object creator/code generator" along the lines of Oracles JPublisher/Oracle, which ripped through the database, creating objects that mapped to the tables, and proxy's for inserting these objects back into the database. It was OK, until I tried to work out how to load these objects at Runtime ... anyway that's another story.

The point is, in the end I decided I was doing things back to front, and started playing with CMP EJB's. This means you define how your beans work, and the persistent fields that need to be stored in the database, and the EJB Container does the rest, mapping the beans to the databse, managing the SQL selects and updates all for you. Ideal.

 

[NathanR]

Would be ideal in lots of situations, but maybe not in my particular situation (which I haven't described). My application is a small one and must be streamlined, I have a hard deadline much too close for comfort, and I have no EJB experience at all, so I probably won't go that way.

However, I'm interested in the approach Maybe next time. For that next time, a question.

I use SQL transactions in my application logic: set serializable, begin transaction, select mail to be sent from list of mails to be sent, update db to say mail is sent, try to send mail, if success commit, if exception caught rollback. I think that should avoid any errors in the "mail sent" status. (Of course I might get a mail bounce, but that's another story).

Would that be possible with the EJB framework you describe?

Thanks for your help!

 

[sedj]

Yes, definitely.

When working with EJB's, (using CMP Entity beans (Container Managed Persistence)) your bean is basically your SQL table, and exceptions are thrown in the same manner as in JDBC (except if the SQL fails, you'll probably get an EJBException rather than an SQLException).

Unitl lately, I never really understood the point of EJB, after all, it is basically buily on RMI (unless you use Local EJBs in EJB spec 2.0), untill I really started to look into it, and learnt that it did all teh backed JDBC stuff and object modelling for you.

Now I'm well impressed with it. It can be a bit difficult to get into, with (at first) complicated xml deployment descriptors, but once you get past that, its plain sailing !

Try "Enterprise JavaBeans 3rd ed." from oreilly.com

http://www.oreilly.com/catalog/entjbeans3/

- the source code can be downloaded with J2EE-vendor-specific (JBoss, WebLogic etc) examples. The author walks you through creating a business model in EJB ....

Good luck !

 

[hologram]

I too worked with EJB's for 2 years. And I am NOT a fan of it. If your current code works, keep it. I don't want to start a discussion pro/contra EJB. You'll have to find out for yourself.