views:

5113

answers:

8

I have several classes that do not really need any state. From the organizational point of view, I would like to put them into hierarchy.

But it seems I can't declare inheritance for static classes.

Something like that:

public static class Base
{
}

public static class Inherited : Base
{
}

will not work.

Why have the designers of the language closed that possibility?

+1  A: 

Hmmm... would it be much different if you just had non-static classes filled with static methods..?

CookieOfFortune
That's what is left to me. I do it this way. And I don't like it.
User
+19  A: 

Citation from here:

This is actually by design. There seems to be no good reason to inherit a static class. It has public static members that you can always access via the class name itself. The only reasons I have seen for inheriting static stuff have been bad ones, such as saving a couple of characters of typing.

There may be reason to consider mechanisms to bring static members directly into scope (and we will in fact consider this after the Orcas product cycle), but static class inheritance is not the way to go: It is the wrong mechanism to use, and works only for static members that happen to reside in a static class.

(Mads Torgersen, C# Language PM)

Other opinions from channel9

Inheritance in .NET works only on instance base. Static methods are defined on the type level not on the instance level. That is why overriding doesn't work with static methods/properties/events...

Static methods are only held once in memory. There is no virtual table etc. that is created for them.

If you invoke an instance method in .NET, you always give it the current instance. This is hidden by the .NET runtime, but it happens. Each instance method has as first argument a pointer (reference) to the object that the method is run on. This doesn't happen with static methods (as they are defined on type level). How should the compiler decide to select the method to invoke?

(littleguru)

And as a valuable idea, littleguru has a partial "workaround" for this issue: the Singleton pattern.

boj
As to your first citation, you can cast an instance class as the base class and then use its public members.
Anthony D
Lack of imagination on Torgersen's side, really. I had a pretty good reason for wanting to do this :)
Thorarin
A: 

By design, it is not allowed to inherit static classes.

Syed Tayyab Ali
+2  A: 

Think about it this way: you access static members via type name, like this:

MyStaticType.MyStaticMember();

Were you to inherit from that class, you would have to access it via the new type name:

MyNewType.MyStaticMember();

Thus, the new item bears no relationships to the original when used in code. There would be no way to take advantage of any inheritance relationship for things like polymorphism.

Perhaps you're thinking you just want to extend some of the items in the original class. In that case, there's nothing preventing you from just using a member of the original in an entirely new type.

Perhaps you want to add methods to an existing static type. You can do that already via extension methods.

Perhaps you want to be able to pass a static Type to a function at runtime and call a method on that type, without knowing exactly what the method does. In that case, you can use an Interface.

So, in the end you don't really gain anything from inheriting static classes.

Joel Coehoorn
+3  A: 

The main reason that you cannot inherit a static class is that they are abstract and sealed (this also prevents any instance of them from being created).

So this:

static class Foo { }

compiles to this IL:

.class private abstract auto ansi sealed beforefieldinit Foo
  extends [mscorlib]System.Object
 {
 }
Andrew Hare
You are saying that static was implemented as abstract + sealed. He wants to know *why* this was done. Why is it sealed?
Lucas
This doesn't answer the question it all; it just restates the issue he was asking about.
Charles
Well, the OP should have asked "Why are static classes sealed", not "Why can't I inherit from static classes?", the answer to which is of course *"because they're sealed"*. This answer gets my vote.
Alex
+1  A: 

What you want to achieve by using class hierarchy can be achieved merely through namespacing. So languages that support namespapces ( like C#) will have no use of implementing class hierarchy of static classes. Since you can not instantiate any of the classes, all you need is a hierarchical organization of class definitions which you can obtain through the use of namespaces

Amit
+1 for organization through namespaces, not inheritance.
Lucas
A: 

Although you can access "inherited" static members through the inherited classes name, static members are not really inherited. This is in part why they can't be virtual or abstract and can't be overridden. In your example, if you declared a Base.Method(), the compiler will map a call to Inherited.Method() back to Base.Method() anyway. You might as well call Base.Method() explicitly. You can write a small test and see the result with Reflector.

So... if you can't inherit static members, and if static classes can contain only static members, what good would inheriting a static class do?

Lucas
+3  A: 

@Mads Torgersen: The only reasons [...] have been bad ones, such as saving a couple of characters of typing.

FAIL... that's what they said of the shift to object-oriented programming. Torgersen needs to try his own dog food.