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.
[EDIT:] 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 ]
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.
posted 13 years ago
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?
posted 13 years ago
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.