Empty interface

?

-

If I have an abstract class AbstractSomeClass and in order to avoid a
situation where passing the parameter requires writing
someMethod(AbstractSomeClass asc), I create an empty interface called
SomeClass and then have AbstractSomeClass implements it so that i can do
a someMethod(SomeClass sc)?
 
S

Stefan Schulz

If I have an abstract class AbstractSomeClass and in order to avoid a
situation where passing the parameter requires writing
someMethod(AbstractSomeClass asc), I create an empty interface called
SomeClass and then have AbstractSomeClass implements it so that i can do
a someMethod(SomeClass sc)?

Personally i'd go for the interface declaring the methods used in
AbstractSomeClass ;-)
 
K

Kevin McMurtrie

If I have an abstract class AbstractSomeClass and in order to avoid a
situation where passing the parameter requires writing
someMethod(AbstractSomeClass asc), I create an empty interface called
SomeClass and then have AbstractSomeClass implements it so that i can do
a someMethod(SomeClass sc)?

Sure, that works if all you want to do is type checking on an object
that you never actually look at. I'm not sure how much use it would be.
Sooner or later you'll want to use the object and you'll either need an
interface that defines methods or you'll need a runtime cast to a class.

Define some methods in the interface and have your AbstractSomeClass
implement it. Then you can type check arbitrary classes and use them
without unsafe runtime casting.
 
J

Jesper Nordenberg

- said:
If I have an abstract class AbstractSomeClass and in order to avoid a
situation where passing the parameter requires writing
someMethod(AbstractSomeClass asc), I create an empty interface called
SomeClass and then have AbstractSomeClass implements it so that i can do
a someMethod(SomeClass sc)?

It's a bad idea to create an empty interface because you need to cast
to AbstractSomeClass everywhere you want to call a method on the
object. You should put all the public methods found in
AbstractSomeClass in the interface. This "adapter" pattern is commonly
used in the JRE (see MouseListener -> MouseAdapter).

If you are creating an interface to which you might add new methods in
the future, the best solution is to also create an abstract base class
that implements the interface and note in the interface documentation
that instead of implementing the interface directly, you should sub
class the abstract class. Otherwise, when you add a method to the
interface you will break all classes directly implementing the
interface, but if they inherit from the abstract base class you can
add a default implementation for the new method to avoid breaking sub
classes.

/JN
 
G

George Cherry

Jesper Nordenberg said:
It's a bad idea to create an empty interface

So, would java.io.Serializable--an "empty" interface--be
a bad idea then? It's called a "marker interface". It indicates
the semantics of an implementing class as being serializable.

George W. Cherry
 
J

Jesper Nordenberg

George Cherry said:
So, would java.io.Serializable--an "empty" interface--be
a bad idea then? It's called a "marker interface". It indicates
the semantics of an implementing class as being serializable.

I'm well aware of the use of marker interfaces, but I don't think the
OP was refering to a marker interface, but rather an interface with
public methods. Btw, in Java 5 many uses of marker interfaces can be
replaced with annotations.

/JN
 
G

George Cherry

Jesper Nordenberg said:
I'm well aware of the use of marker interfaces, but I don't think the
OP was refering to a marker interface, but rather an interface with
public methods.

I'm a little confused by the above. If an interface has
methods, then it isn't empty, and all methods in an
interface are public (because it's a specification of
a contract between the class which implements the
interface and any user of the class).

Btw, in Java 5 many uses of marker interfaces can be
replaced with annotations.

Interesting. What does one gain by replacing marker
interfaces with annotations?

GWC
 
J

Jesper Nordenberg

George Cherry said:
I'm a little confused by the above. If an interface has
methods, then it isn't empty, and all methods in an
interface are public (because it's a specification of
a contract between the class which implements the
interface and any user of the class).

Correct. I don't see the cause of your confusion.
Interesting. What does one gain by replacing marker
interfaces with annotations?

Annotations are more powerful than marker interfaces, for example they
can be inherited to sub classes or not (interfaces are always
inherited), and they can have parameters.

/JN
 
G

George Cherry

Jesper Nordenberg said:
Correct. I don't see the cause of your confusion.


Annotations are more powerful than marker interfaces, for example they
can be inherited to sub classes or not

Why is this an advantage? Doesn't it break
the polymorphism contract?
Polymorphism: an object of a given class can
have multiple forms, either its own class or
any class it extends. If a class does not honor
all the contract of its superclass, doesn't it break
polymorphism?

George W. Cherry
 
J

Jesper Nordenberg

George Cherry said:
Why is this an advantage? Doesn't it break
the polymorphism contract?
Polymorphism: an object of a given class can
have multiple forms, either its own class or
any class it extends. If a class does not honor
all the contract of its superclass, doesn't it break
polymorphism?

Yes, it breaks polymorphism, but in the case of marker interfaces
without methods you don't have much polymorphism anyway. Actually, in
the serialization framework of a project I'm involved in
(jcore.dev.java.net) we've been pondering the different aspects of
marker interfaces and annotations with regard to marking a class as
serializable. We decided on using an annotation that is not inherited
to sub classes, as this will force developers to explicitly mark their
classes as serializable and thus think about the serialization issue.
Serializing instances of classes not marked as serializable will cause
a runtime exception. We feel that this better than automatically
inheriting the serializable attribute from the super class, and
possibly do incorrect serialization of the class instances
(serializing fields that should be transient, incorrect versioning
etc.).

/JN
 
G

George Cherry

Jesper Nordenberg said:
Yes, it breaks polymorphism, but in the case of marker interfaces
without methods you don't have much polymorphism anyway. Actually, in
the serialization framework of a project I'm involved in
(jcore.dev.java.net) we've been pondering the different aspects of
marker interfaces and annotations with regard to marking a class as
serializable. We decided on using an annotation that is not inherited
to sub classes, as this will force developers to explicitly mark their
classes as serializable and thus think about the serialization issue.

Ahh, that's a distinct advantage. GWC
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top