Interfaces

[djbaker2]

Is there any way when implementing an interface (in this example the
java.sql.Connection interface) to avoid having to override the methods
declared in there. I know that this is the whole point to interfaces
and this question goes against the very essence of them but i am
clutching at straws Thanks for any answers

 

[Ingo R. Homann]

Hi,

Is there any way when implementing an interface (in this example the
java.sql.Connection interface) to avoid having to override the methods
declared in there. I know that this is the whole point to interfaces
and this question goes against the very essence of them but i am
clutching at straws Thanks for any answers

No. The methods must be implemented. But of course, the implementation
may be trivial, so that the compiler will accept it and no one gets hurt
if the method is not called at runtime:

public void foo() {
throw new UnsupportedOperationException();
}

Any good IDE should support you in implementing all necessary methods.

Hth,
Ingo

 

[djbaker2]

Cool, thanks. I use netbeans, but this is code wrote by someone else.
They claim that they have had it compiling in the past but they can't
have done because there is this class that doesn't implement the
necessary methods. I was just wondering if there was a way they could
have got around it.

 

[Robert Klemme]

Cool, thanks. I use netbeans, but this is code wrote by someone else.
They claim that they have had it compiling in the past but they can't
have done because there is this class that doesn't implement the
necessary methods. I was just wondering if there was a way they could
have got around it.

Well, you can - in a way: define an interface, create a class that
implements all methods of that interface, add methods to the interface
but do *not* recompile the class.

Practical example, java.sql interfaces were extended during the course
of JDBC evolution but you can still use an old JDBC driver even with a
newer JDK if you constrain yourself to the old methods. The will
application run perfectly until a non implemented method is invoked in
which case you will get an error (NoSuchMethod error I believe, but
could also be one of AbstractMethodError and IncompatibleClassChangeError).

Kind regards

robert

 

[Lew]

Well, you can - in a way: define an interface, create a class that
implements all methods of that interface, add methods to the interface
but do *not* recompile the class.

Practical example, java.sql interfaces were extended during the course
of JDBC evolution but you can still use an old JDBC driver even with a
newer JDK if you constrain yourself to the old methods. The will
application run perfectly until a non implemented method is invoked in
which case you will get an error (NoSuchMethod error I believe, but
could also be one of AbstractMethodError and IncompatibleClassChangeError).

Another dodge that is not a mistake is to use an abstract implementation of
the interface, typically one whose methods do nothing or throw
UnsupportedOperationException, then derive the "real" classes from the
abstract class.

interface Foo
{
void method();
}
abstract class AbstractFoo implements Foo
{
public void method()
{
return new UnsupportedOperationException();
}
}
class ReallyDoesFoo extends AbstractFoo // should compile without error
{
}

You see this in the Collections framework (AbstractList, ...)

 

[Robert Klemme]

Another dodge that is not a mistake is to use an abstract implementation
of the interface, typically one whose methods do nothing or throw
UnsupportedOperationException, then derive the "real" classes from the
abstract class.

interface Foo
{
void method();
}
abstract class AbstractFoo implements Foo
{
public void method()
{
return new UnsupportedOperationException();
}
}
class ReallyDoesFoo extends AbstractFoo // should compile without error
{
}

You see this in the Collections framework (AbstractList, ...)

Or even:

interface Foo
{
void method();
}
abstract class AbstractFoo // no interface here!
{
public void method()
{
return new UnsupportedOperationException();
}
}
class ReallyDoesFoo extends AbstractFoo implements Foo
{
}

Yeah, true. Rereading the original posting this also seems a possible
scenario. I had assumed that the method were plain missing. Thanks!

Kind regards

robert

 

[bugbear]

Is there any way when implementing an interface (in this example the
java.sql.Connection interface) to avoid having to override the methods
declared in there. I know that this is the whole point to interfaces
and this question goes against the very essence of them but i am
clutching at straws Thanks for any answers

Short answer: no
Longer (more helpful answer)... but you extend an Abstract<blah>
or <Blah>Adapter

examples:
java.awt.event.MouseAdapter
java.util.AbstractSet

BugBear

Sadly, conventional pattern language uses "adapter" to mean something quite different.

 

[Adam Maass]

Cool, thanks. I use netbeans, but this is code wrote by someone else.
They claim that they have had it compiling in the past but they can't
have done because there is this class that doesn't implement the
necessary methods. I was just wondering if there was a way they could
have got around it.

Sounds like it was compiled against an earlier version of the interface, one
that didn't include all of the methods.


-- Adam Maass