Hi all, Isn't it true that when you use an interface you need to give a definition for all the methods in the interface? Well, i am confused, because when you use the Statement interface in java.sql.*, you can write a line of code like: resultset = statement.executeQuery(query); but you never define how the executeQuery method works. Since executeQuery() is a method in the Statement inteface, should I not first give a definition for the mothod ? but how does it work anyway considering an interface does not give the definition for any of its methods but just declares them?? kinda long doubt but plz help me ... thank you... -P
You obtain that statement object by using a createStatement method in Connection. The createStatement method, not your code, is responsible for constructing and returning an object of a class that implements the Statement interface. Your code doesn't care what that class is--it interacts with the object using the Statement reference. -j-
I could not get how it would happen. because when you say DriverManager.getConnection() we get the connection object which is a connection(interface) object. but driver manager object never implements statement object. and statment is again an interface and where does it implement the executequery methods. what is the total way of executing and where does the method definitions come can you explain a bit clearly. thanks and regards shekar.
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 ]
Joined: Jan 22, 2004
Thanks, I appreciate that What I'm curious about, however, is this: Are you (Prashanth Naidu) attempting to write your own class that implements the Statement interface (you are writing your own database classes) or are simply using the standard createStatement()? That does make some difference in this disccusion. If you are writing your Statement, then yes, you will have to implement all of Statement's methods yourself. Otherwise, no, you do not. Hope this helps.