Chris Adams wrote:
006b01c1bae8$ca8e0a90$[EMAIL PROTECTED]">
For those out there who know English -
I'd like your opinion...
This is more a Java question than EJB,
but relevant nonetheless...
If you are familiar with Bruce Eckel's
Java Bible (http://www.mindview.net
) Thinking in Java - you'll notice that he is quite adamant about the use
of interfaces as a contract for those who implement it - and that it doesn't
carry any implementation. Its purpose is to manage new subclasses and stating
to the world that if you implement an interface, you will have at least
your own implementation of those interface methods. THis, of course, is
the mechanism that gives us the power of dynamic binding.
Given this... I was digging through the
java.sql.* package and found several classes - INTERFACES - that HAVE implementation
defined. java.sql.callableStatement for example.
I can understand we would want to override
methods in callableStatement if we want to make our own subclass of it ...but
I would expect this to be a normal class and then I would extend it with
my own. More so, I didn't think you could even compile a class defined
as an interface if it contained method implementation. Going to start some
of my own tests now to prove this, but anyone know why CallableStatement
and others would be interfaces rather than normal classes. And is this
more common than I thought?
In any application using java.sql, all you do is import java.sql this is
completely independent of driver/database. The implementation is done by
the Database manufacturer. As you will see in the oracle documentation these
interfaces have been implemented. JDBC uses polimorfism and factory methods.
Any JDBC Driver should have implementations of these interfaces (OracleCallebleStatement
for example). JDBC is a framework and and not an implementation.
006b01c1bae8$ca8e0a90$[EMAIL PROTECTED]">
Thanks,
Chris
