.NET Questions (CLOSED)

Questions and Answers on any aspect of .NET. Now closed.

This discussion group is now closed.

Have a question about .NET development? Try stackoverflow.com, a worldwide community of great developers asking and answering questions 24 hours a day.

The archives of .NET Questions contain years of Q&A. Even older .NET Questions are still online, too.

Why can't you have static methods in an Interface?

Why can't you have static methods in an Interface?
Newbie
Wednesday, February 08, 2006
 
 
Because an interface is a "contract" or an agreement between the consumer (caller) and the provider (callee). An interface describes what and how the calle will provide functionality. There is no need for static members provided by a third party. Static members cannot be overridden by a provider so they do not belong in an interface.

In java interfaces can have static members, and this is primarily used as a work around for not having enums.
Stefan Rusek Send private email
Wednesday, February 08, 2006
 
 
Stefan, you pretty much just answered the question by saying "because you just can't, ok?". The real question becomes, why does Java allow you to do this when C# doesn't? I could argue either way on this issue. I personally prefer the way that Java handles static members better than the way that C# does it. But that's just me.
anon
Wednesday, February 08, 2006
 
 
Stefan didn't say "because you just can't"; he said "because you just shouldn't".
smalltalk Send private email
Wednesday, February 08, 2006
 
 
Good point smalltalk!  :)
anon
Wednesday, February 08, 2006
 
 
One exception is factory methods:

static IFoo* IFoo::CreateFoo();

Strictly speaking, this doesn't have to be (and some would say should not be) part of the interface, but at least to me it seems natural to express the factory method(s) as static method(s) of the interface.
BillT Send private email
Wednesday, February 08, 2006
 
 
Because Java doesn't make a big distinction between a interface and a class while C# does.

Of the two I prefer the C# way as it clearly separates the two concepts rather than class is a class if declared this way but declared another it is a interface that only be implemented.

However I feel that every C# class should have a implicit interface associated with so that you can have another class implement. This very useful for testing as the ability to implement (instead of inheirting) allows better control over how the test object world (few side effects.
Rob Conley Send private email
Thursday, February 09, 2006
 
 
I've found the lack of static methods in C# is sometimes a pain, when you want part of the contract for an object to include a static function that allows itself to be created from something other than a constructor.

The way I've worked around that is to add a custom attribute and tag my "creator" functions with it. That means when I want to instantiate an object from this function without knowing what the type or the function are in advance, I can see if it supports my custom attribute.

This seems to work, but is obviously slower as you have to trawl through the metadata for each class you're interested in.
Ritchie Send private email
Monday, February 13, 2006
 
 
Yeah, there's nothing in the concept of interfaces or public contracts that would prevent them from including static methods. This restriction is only because interfaces use class-like polymorphism which has the same restriction in .NET/C#. I agree it's often a pain. Sadly, the only option is to add a request to the interface comments: "Please also implement static method XYZ when implementing this interface..."
Chris Nahr Send private email
Monday, February 13, 2006
 
 
> static IFoo* IFoo::CreateFoo();

I implement this as a separate factory interface:

interface IFooFactory
{
  IFoo CreateFoo();
}
Christopher Wells Send private email
Tuesday, February 14, 2006
 
 
I can't imagine how Java allows for static methods in interfaces.  (I am not a Java programmer.)

interface IFoo
{
    static int Fee();
}

class AFoo : IFoo
{
    static int Fee(){ return 1; }
}

class BFoo : IFoo
{
    static int Fee(){ return 2; }
}

What does IFoo.Fee() return in Java?
Rob Send private email
Thursday, February 23, 2006
 
 
The proble with static methods in an interface is you're breaking polymorphism to get polymorphism.

The point of an interface is polymorphism.  you don't have to know exactly what class you're dealing with, you just know it has a couple known methods/properties to it.  Statics on the other hand are designed so that you have a well known location for a method/property, and don't need an instance of the object to work with it.  The two concepts are diametrically opposed.

I would evaluate *why* you need a static method in a interface.  Would a factory method to return an instance of the correct class (which could implement the interface!) not work?  What about reflection?

Activator.CreateInstance comes to mind:

public interface IFoo
{
  void HasSomeMethodINeed();
}

public static IFoo CreateFoo(string nameOfFooClass)
{
  return (IFoo)Activator.CreateInstance(Type.GetType(nameOfFooClass));
}
another anonymous coward
Thursday, March 02, 2006
 
 
You can actually do this in IL.

Cheers,

Greg
Greg Young Send private email
Thursday, March 02, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz