static method in interface?

B

bauscharln

hoi,
I just wanted to add a static method to my interface, but that's not
allowed!
Is there a reason for this???
(Yes, I could make an abstract base class, but that's not what I want,
since I don't need an implementation.)

thank you in advance,
bauscharln
 
M

Marina

I think it's cause interfaces really exist for polymorphic reasons. So when
you have an instance of an object and you want to call a method on it, you
don't need to care about its type, just that it implements an interface.

But for static methods, there is no instance to speak of.
 
B

bauscharln

Marina said:
I think it's cause interfaces really exist for polymorphic reasons.
But for static methods, there is no instance to speak of.

That makes sense! I just wanted to force myself to continuous
programming, and didn't think of polymorphism at all...

thank you!
 
B

Bruce Wood

This question has come up before, and I still have the same reaction to
it.

What would a static method on an interface mean? I can think of two
possible interpretations:

1. It might mean, "Whatever class implements this interface must also
supply a static method with this name and this signature." So, in this
situation, if the interface declared a static property, this would not
represent a single static property but rather a static property that
every implementer had to export.

2. Or, it might mean, "This method is associated with this interface
name. You can call the method IMyInterface.MyStaticMethod() and it will
do something." This involves allowing interfaces to contain (static)
method definitions, and then potentially (static) state, which they
don't currently contain at all.

The first is a way to tell the implementing programmer that there is a
method or property that really doesn't fit as an instance property but
should be implemented in every implementing class. I've had this come
up from time to time. However, this really doesn't buy you much from
the point of view of polymorphism, unless you're using Reflection to go
after an instance's Type and then invoking the static method / property
from there. Even though this is a nice bell (or whistle), it really
doesn't solve any earth-shattering problems.

The second is a way of associating code that belongs with the interface
as a whole and doesn't really fit into any one class. I've run across
this, too, but in the end found it much more sensible to create a
singleton class that works along with the interface, providing services
for implementing classes as well as the aforementioned static methods.
This is a much more flexible design, which led me to believe that the
original idea of a static method attached to the interface was a bad
one.

In the end, I guess there's just no good reason to include it in the
language. Neither interpretation is compelling.

By the way, the only talk I've heard of interfaces having code
associated with them was Anders Hejlsberg's mention that it would be
useful to allow the definition of alternate calling signatures for
methods in interfaces, where one overload just calls another with
default parameters, or some such thing. He said, "I can see the need
for associating some code with interfaces, but never state. As soon as
you allow state it becomes a class." He didn't say anything about
static state.
 

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

Top