static methods in interfaces

[ballpointpenthief]

Is there a nice workaround for this?
I wanted to have a some static methods in an interface, but as you
probably know that's not legal.

This is what I'm trying to do:
Each object that implements this interface needs to handle certain
tasks (File parsing/writing, small JFrames etc...) in a way that is
specific to that particular class.
When the objects are being passed around, they are being passed around
with the interface type, but I need to be able to invoke their specific
methods.

Static methods declared in the interface would be ideal, but for some
reason this isn't allowed (why not?)
I'm guessing any workarounds may involve static variables, reflection
or C++.

Thanks,
Matt

 

[Andrew Thompson]

ballpointpenthief wrote:

Sub: static methods in interfaces

<sscce>
public interface TheInterface {
/** Left to implementers. */
public abstract Object theMethod();
}

class TheClass implements TheInterface {
public Object theMethod() {
return this;
}
}
</sscce>

Andrew T.

 

[ballpointpenthief]

Firstly,
I can't see how the use of the abstract keyword in an interface
changes anything at all here. Could someone explain this?

Secondly, I think you may have skimmed my post:
For example, one of the methods will be a JFrame getEntryForm()
which will return a frame specific to the class in order to create a
new instance. This obviously should be a static method - there might
not even be any instances of that class. (Short of creating one by
invoking it's constructor, calling the method, and discarding it
after.)

Hope I've not misunderstood anything,
Matt

 

[Rogan Dawes]

Is there a nice workaround for this?
I wanted to have a some static methods in an interface, but as you
probably know that's not legal.

This is what I'm trying to do:
Each object that implements this interface needs to handle certain
tasks (File parsing/writing, small JFrames etc...) in a way that is
specific to that particular class.
When the objects are being passed around, they are being passed around
with the interface type, but I need to be able to invoke their specific
methods.

Static methods declared in the interface would be ideal, but for some
reason this isn't allowed (why not?)
I'm guessing any workarounds may involve static variables, reflection
or C++.

Thanks,
Matt

You seem to be breaking the object oriented behaviour of your model.

However, if you are sure that you want to do this, the way to do this is
to use "instanceof" or equivalents, and casting:

Shape shape = getShape();
if (shape instanceof Square) {
Square square = (Square) shape;
square.setSide(2);
}
shape.drawShape();

Hope this helps,

Rogan

 

[ballpointpenthief]

Hopefully this is a SSCCE:
(I have reason not to use an abstract class.)

public interface TheInterface {
public static String getSomethingReleventToClass();
}

public Class AClass implements TheInterface {
private String somethingReleventToClass = "This will be different
in each class";
public static String getSomethingReleventToClass() {
return somethingReleventToClass;
}
}

public Class Application {
private TheInterface someClass;
public Application() {
someClass.getSomethingReleventToClass();
}
}

Cheers,
Matt

 

[Chris Uppal]

I can't see how the use of the abstract keyword in an interface
changes anything at all here. Could someone explain this?

It doesn't; all methods declared in interfaces are necessarily public and
abstract -- whether you say so or not ;-)

For example, one of the methods will be a JFrame getEntryForm()
which will return a frame specific to the class in order to create a
new instance.

I think you may be looking for the "Factory Object" pattern. Google (or
whatever search engine you favour) will turn up the details easily.

-- chris

 

[Jhair Tocancipa Triana]

When the objects are being passed around, they are being passed around
with the interface type,

If this were the case. What is the problem with that?

but I need to be able to invoke their specific methods.

You can invoke the methods in the classes which implement the
interface.

Static methods declared in the interface would be ideal, but for
some reason this isn't allowed (why not?)

You are totally confused. Interfaces just specify the signatures of
the methods that *must* be implemented by classes which implement the
interface.

 

[Rogan Dawes]

Hopefully this is a SSCCE:
(I have reason not to use an abstract class.)

public interface TheInterface {
public static String getSomethingReleventToClass();
}

public Class AClass implements TheInterface {
private String somethingReleventToClass = "This will be different
in each class";
public static String getSomethingReleventToClass() {
return somethingReleventToClass;
}
}

public Class Application {
private TheInterface someClass;
public Application() {
someClass.getSomethingReleventToClass();
}
}

Cheers,
Matt

Ok, notice that in your code here, you actually have an INSTANCE of
TheInterface in class Application. So, the way you are invoking
getSomethingRelevantToClass is correct, IF you were not attempting to
define getSomethingRelevantToClass statically.

From your previous emails, it sounded like you actually only wanted to
pass the class name around, or Class object, to be precise. As far as I
know, the fundamental problem with your approach is that since you
cannot define static methods on an interface, you cannot do something like:

interface TheInterface {
public static String getSomethingRelevantToClass();
}

and hope to do:

TheInterface.getSomethingRelevantToClass();

However, I think that you will find that they way you wrote it above is
99.9% correct, if you have INSTANCES of classes implementing
TheInterface, just take out the "static" when defining your TheInterface
class.

This is actually entirely standard OO programming in Java.

Rogan

 

[Patricia Shanahan]

Hopefully this is a SSCCE:

Only something that compiles can be an SSCCE, but it is an SSCE (static
self-contained example).

(I have reason not to use an abstract class.)

public interface TheInterface {
public static String getSomethingReleventToClass();

Why does this need to be static?

}

public Class AClass implements TheInterface {
private String somethingReleventToClass = "This will be different
in each class";

If it is associated with the class, why isn't this static?

public static String getSomethingReleventToClass() {
return somethingReleventToClass;
}
}

public Class Application {
private TheInterface someClass;
public Application() {
someClass.getSomethingReleventToClass();
}
}

I would just make getSomethingRelevantToClass an instance method, in
both the interface and the implementation. Instance methods can
reference static variables just as well as static methods can. On other
hand, in any implementation in which somethingRelevantToClass is
correctly named, I would make it a static variable.

There can't be any problems with needing to call the method through the
interface without an object existing. Interfaces are inherently
abstract, so you can't do anything much with them other than access
constants unless you have an instance of an implementing class.

Patricia

 

[Andrew Thompson]

Only something that compiles can be an SSCCE, but it is an SSCE (static
self-contained example).

good one ;-)

For the OP, the SSCCE is described here..
<http://www.physci.org/codes/sscce>

A.

 

[ballpointpenthief]

ballpointpenthief wrote:

Only something that compiles can be an SSCCE, but it is an SSCE (static
self-contained example).

sorry, I meant SSCunCE.
It should now be clear why this can't be an instance method (there
might not event *be* any instances)
public interface TheInterface {
public static String getSomethingReleventToClass();

}

public Class AClass implements TheInterface {
private static String somethingReleventToClass = "This will be
different
in each class"; // *** I've changed this to static here ***
public static String getSomethingReleventToClass() {
return somethingReleventToClass;
}

}

public Class Application {
private TheInterface someClass;
public Application() {
someClass.getSomethingReleventToClass();
}
}

Cheers,
Matt

 

[Patricia Shanahan]

sorry, I meant SSCunCE.
It should now be clear why this can't be an instance method (there
might not event *be* any instances)

I don't see how that could work with interface-specified static
methods.

If you have the class name, but not an instance, you could invoke a
static method directly.

If you have neither the class name nor an instance, how is the compiler
supposed to pick a class to call a static method?

I strongly suspect that interface is not the right way to solve your
design problem, but I don't know enough about the problem to know how to
deal with it. Perhaps you could describe the intent at a higher level?

Patricia

 

[ballpointpenthief]

If you have the class name, but not an instance, you could invoke a
static method directly.

I don't have the class name, I have an Class of TheInterface type.
For what it's worth; I have 6 classes being passed to the same object
(lets call this object Impossible).
Certain actions require different behaviour, and these happen to be
relevant to the class type (hence the use of static).

If you have neither the class name nor an instance, how is the compiler
supposed to pick a class to call a static method?

I was expecting to be able to let Impossible (see above) call these
static methods directly on the Class<TheInterface>, and the Virtual
Machine would get the procedure relevant to that class.

I strongly suspect that interface is not the right way to solve your
design problem, but I don't know enough about the problem to know how to
deal with it. Perhaps you could describe the intent at a higher level?

I suspect one of a few things is going on; including:

- I have overlooked/am confused by something in the language.
- I've just ran into a limitation of Java.
- My design is crap, and no-one programmes like that anyway.

I haven't a clue which one though.

Cheers,
Matt

 

[Patricia Shanahan]

I don't have the class name, I have an Class of TheInterface type.
For what it's worth; I have 6 classes being passed to the same object
(lets call this object Impossible).

I'm having a lot of trouble parsing this paragraph. When you say you
have "an Class" do you mean the java.lang.Class object for the type? I
have no idea what you mean by "being passed to the same object".

Time for another SSC(C)E?

I suspect one of a few things is going on; including:

- I have overlooked/am confused by something in the language.
- I've just ran into a limitation of Java.
- My design is crap, and no-one programmes like that anyway.

I haven't a clue which one though.

I would hesitate to call another programmer's design "crap", but
otherwise, yes, those are some possibilities. It is very hard to work
out which without knowing what problem the design is intended to solve.
That is why I'm suggesting describing the problem at a higher level.

Patricia

 

[ballpointpenthief]

Hello,
In case anyone is interested, I have been pointed to the most recent
post on
http://www.jguru.com/faq/view.jsp?EID=88225
- (at least it was the last post - Aug 10 2006 by Alex Kineer)

I never did find a workaround though...

Cheers,
Matt

 

[Lew]

It isn't so much a "limitation" of Java as a feature, but static methods do
not override, so it doesn't make any sense to declare a static method in an
interface.

You could define an interface with non-static methods that do exactly what you
want. Then the implementors can override the methods. What matter that an
instance performs those actions instead of a class?

If you are really averse to creating instances, use a non-instantiable class
that has all the static methods you need. Don't even try to think of them as
overrides; think of them as separately-named methods that do what you wanted
the separately-named classes to do.

Your design is thus not "crap", just implemented in a slightly different way
from your first intuition. Still the same design, fundamentally.

- Lew

 

[ballpointpenthief]

I think you may be looking for the "Factory Object" pattern. Google (or
whatever search engine you favour) will turn up the details easily.

-- chris

Thankyou - this looks very promising.

 

[Matt Atterbury]

Hopefully this is a SSCCE:
(I have reason not to use an abstract class.)

public interface TheInterface {
public static String getSomethingReleventToClass();
}

public Class AClass implements TheInterface {
private String somethingReleventToClass = "This will be different
in each class";
public static String getSomethingReleventToClass() {
return somethingReleventToClass;
}
}

public Class Application {
private TheInterface someClass;
public Application() {
someClass.getSomethingReleventToClass();
}
}

The point that Patricia et al were trying to make is that "someClass"
must be a reference to an instance of a class that implements
"TheInterface".

Therefore, making "getSomethingReleventToClass" (sic) non-static will
work just fine.

You seem to be unclear on just what "someClass" is. Perhaps you need
to put some thought/explanation into how "someClass" will be set, as
then you will (probably) realise the flaw in your reasoning?

This is why people expect/require an example that *compiles* (or in
your case, would compile if you could have static interface methods).

m.

 

[Andrew Thompson]

It doesn't; all methods declared in interfaces are necessarily public and
abstract -- whether you say so or not ;-)

Huh! I would not have believed that if my compiler
had not just confirmed it. (grumbles) ..and all
those times I type 'public abstract '...

( Still - old habits.., I'll probably *continue* to add them

Andrew T.

 

[Chris Uppal]

Andrew Thompson wrote:

[me:]

Huh! I would not have believed that if my compiler
had not just confirmed it. (grumbles) ..and all
those times I type 'public abstract '...

( Still - old habits.., I'll probably *continue* to add them

FWIW, the "standard" recommendation from Sun is to omit them. I don't normally
have much time for Sun's recommendations, but in this case I agree with them,
and it seems that much of the rest of the Java programming community do too.

I don't know how much weight you give to conformance with "common practice"
(very little, I suspect), but I do think there are good-ish reasons to leave
them out beyond the fact that Sun recommend it.

Some are (in no special order):

a) Saves typing and reading.

b) Saves layout (I lay real methods out as
access flags, return type
method(params)
thows exceptions
{
...
}
but I prefer to put interface "method declarations" all on one line
where possible, so reducing the number of words helps.

c) Reduces the (misleading, IMO) apparent similarity between method
declarations in classes and the "method declarations" in interfaces.

-- chris