I agree with both of Jason's posts
Chandra asked for the whole flow and an understanding of all the interfaces, objects and methods involved in getting to a statement.... here's my stab at it.
First, to understand one point... An interface is like a set of requirements handed to a developer. You spell out "it needs to do this, and that", and 5 different developers might
implement your requirements, but if they've all done their job correctly,
you should be able to call this() and that() on an object of any of their classes. Also note that if an object is of a type (class) that
implements an interface, it can be referenced by a variable whose type is that interface. So, for example:
is perfectly valid. We have a reference of type A (the interface) refering to an object of type B (a class that implements the A interface). We can do this because B "IS-A" A, and calling methods declared in A results in the implementation defined in B (in this case, "Hello World" is printed).
The beauty of this, is that if someone hands us an object of type B, we don't have to know anything about it (including the class name), as long as we know that it implements A, because we can trust that it is possible to call the doStuff() method on it. Whether it does anything meaningful is another point....
The case of
JDBC is the same. We have the interfaces Driver, Connection, Statement, ResultSet, etc., that are all defined by the JDBC API. The classes that
implement them are in the JAR file containing the JDBC driver class. Those classes may implement a lot MORE than just what is guaranteed in the interfaces, but we know we can AT LEAST call the methods in the API.
So here's some sample JDBC code:
Line by line (forgive the redundancy, but it shows that it's the same concept repeated over and over):
1. defines a
string named "driverClassName" that contains the name of a valid class for a JDBC driver, such as the JDBC-ODBC bridge driver, or a driver provided by a database vendor such as Oracle or Informix. This class would be defined in a JAR file supplied by the vendor, and in the CLASSPATH of the program.
2. defines a string named "url" which contains the parameters for a database connection. In this case, only the ODBC datasource name.
3. the Class.forName().newInstance() instantiates an object of the Class named by "driverClassName", which is then cast as a Driver, and assigned to the reference variable "driver". Driver is an interface, but we're getting a class (called sun.jdbc.odbc.JdbcOdbcDriver) which implements it, so we can call all the methods defined in that interface, and get the implementations defined in that class.
4. DriverManager.registerDriver(driver) loads that object-which-implements-Driver into the DriverManager, so that later, if we ask the DriverManager for a Connection, it'll know what Driver class to use to instantiate the Connection.
Note that registerDriver() is a static method, our code doesn't ever have a DriverManager object reference. 5. And here that's what we're doing. Straight from my copy of the javadoc for DriverManager:
When the method getConnection is called, the DriverManager will attempt to locate a suitable driver from amongst those
...that have been loaded to this point. So this gives us an object-which-implements-Connection, which we'll assign to a Connection reference, and make Connection method calls against. In reality, the class may be called "sun.jdbc.odbc.JdbcOdbcConnection" or something similar.
6. Now we're calling the createStatement() method on that object-which-implements-Connection. It doesn't return a java.sql.Statement object (no such thing), it returns an object-which-implements-Statement (possibly a "sun.jdbc.odbc.JdbcOdbcStatement"). Again, the code for that class implementation is probably in the JAR file with the JDBC driver. We don't care what it's called, we just call Statement methods against it.
7. Same thing for ResultSet. ObjectWhichImplementsStatement.executeQuery() will return an object-which-implements-ResultSet, the particular implementing class being defined in that same JAR file.
Hope this helps.... one way
or another
-- Jon
[ March 24, 2004: Message edited by: Jon Egan ]