This week's book giveaway is in the OO, Patterns, UML and Refactoring forum.
We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line!
See this thread for details.
The moose likes Java in General and the fly likes Object Instantiation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

JavaRanch » Java Forums » Java » Java in General
Bookmark "Object Instantiation" Watch "Object Instantiation" New topic

Object Instantiation

Chris Montgomery
Ranch Hand

Joined: Jan 14, 2004
Posts: 141
I'm finding I am working with a few objects quite often and in more than one class.

For example the ResultSet object.

Would it be okay to create a class like this:

Then have all my classes that use rs and conn extend my Objects class.
Result being I don't have to instantiate the rs and conn objects each time I need them.

Is this bad, good?
Just wondering if there are any issues with this approach.
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1040
Two things:

1) You may want to pick a better name. Rather than "Objects", you might try something that describes WHY such a subclass would have a ResultSet and a Connection. Perhaps DBAccessor, or something similar would be more descriptive.

2) Favor composition over inheritance. Rather than subclassing Objects, any new class that needs to access the DB should just include a field of type Objects. That way, the new class will have all things it needs with one field without having to subclass Objects.

Oh wait, now I see that you made the ResultSet and Connection static. I'm not sure that's such a good idea. If you ever enhance your program to be multi-threaded, you will have issues with multiple threads using the one ResultSet object. This is true even if you use subclassing/inheritance instead of composition.
[ December 02, 2005: Message edited by: Ryan McGuire ]
Paul Clapham

Joined: Oct 14, 2005
Posts: 19719


For one thing, you've declared the variables static, so all instances of all subclasses of that class would share a single copy of the variables. That may not be a good idea.

But more to the point, making other classes extend that class is the wrong thing to do. Having a class that contains Connection and ResultSet objects may be a good idea, but other classes should just use it, not extend it. Inheritance is often overused by Java programmers, and for beginners it's hard to tell when to use it. The rule of thumb I use is, if somewhere in your code you have to have "Objects abc = new SomeClass()" then SomeClass needs to extend Objects. If not, then it is likely sufficient for SomeClass to contain a reference to some Objects object and use that.
Chris Montgomery
Ranch Hand

Joined: Jan 14, 2004
Posts: 141
as of now, I have a class that contains all my "actions". These actions are simply methods that interact with the database.


each one of these needs a connection and sometimes a result set.

do I do this:

in EVERY method?

Or do I do only do it once at the top of my class,so that all methods have access to the variables?
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1040
It depends on the lifetime of an object of that class. One possibility is to create a new Objects in the client classes constructor. You might also initialize the connection at that point as well. Then the methods can use the Connection and ResultSet at their leasure.

I'm pretty sure that the Connection will automatically release any system resources it has when it gets garbage collected, so you can just let the Objects object go out of scope or set the variable to null when you're done with it.

If, on the other hand, this one object will have a long lifetime and many other objects will want access to the DB, you might not want to hog the open Connection. Instead, you might want to do exactly what you feared and have each method instantiate and initialize (open the Connection of) its own Objects object.
I agree. Here's the link:
subject: Object Instantiation
It's not a secret anymore!