static interface and static abstract class

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

Hi,

I know static classes are seen as dirty. I know the interface and abstract class need to be instantiated.

Still I would love for there to be a "static interface" - an interface that you could put on a static class.
And I would also love a static abstract base class with static virtual methods that you can override in another static class.
This is because I find it very usefull to do all my inheritance on models, and then have static classes for specific logic.

These business classes are static because you can't instantiate them, and every method has to work only with it's parameters.

Right now, loosing inheritance is a big price to pay, but when all inheritance is already done, I experiance it as a very clean way of programming.
Could you please consider adding an static interface and a static abstract class to our language c#?

With kind regards,

Ingmar

[TahirAhmadov]

#5783 #4436

[DavidArno]

I'm struggling to understand how static interfaces and static abstract classes would work. What would you do with them? For example, take the following code:

interface IObjectExample
{
    void Foo();
}

abstract class ObjectExampleBase : IObjectExample
{
    public abstract void Foo();
}

class ObjectExample : ObjectExampleBase
{
    public override void Foo() {}
}

void Example(IObjectExample obj) => obj.Foo();
var o = new ObjectExample();
Example(o);

I can have a method that takes an IObjectExample and pass an instance of ObjectExample to that. That's because we have objects (instances of classes) as well as the classes themselves.

But what then happens if this is all static:

static interface IClassExample
{
    static void Foo();
}

static abstract class ClassExampleBase : IClassExample
{
    public static abstract void Foo();
}

static class ClassExample : ClassExampleBase
{
    public static override void Foo() {}
}

void Example(IClassExample thing) => thing.Foo();

What is thing here? It's not an object as you can't have an instance of a static class. Would I just call it via Example(ClassExample)? What does that give me that Action doesn't?

It would be interesting to see a use-case for all of this that is compelling compared with using delegates, which seems to me to already cover all this.

[DavidArno]

Oh, that's clever. That certainly is an interesting idea.

[HaloFour]

That works today :)

[DavidArno]

It really does 🎉

That's amazing. I hadn't got the point of abstract statics in interfaces until now. Much appreciated.

[DavidArno]

I think it'd also be kind of nice if static types could implement interfaces with instance members and behave like companion types with a singleton instance, but that'd be a very different approach.

Being able to apply an interface that only defines abstract/virtual statics to a static class does feel like an obvious vNext candidate. I guess the challenge is that that would either need a runtime change or it would have to "fake" the static aspect via making it sealed with an intrinsic private constructor and have it be non-static in the runtime.

I guess that will be a true "let's see if there's demand" potential feature.

[HaloFour]

Static classes don't exist in the runtime, they are strictly a C# syntax feature. I think supporting interfaces with only static abstract members on static classes would be a matter of removing that imposed limitation of static classes not being able to implement interfaces, at least in this particular case. Question is whether there is any interest in doing so.

[ingmarcrone]

Hi there,

It is hard to show a good use case because it isn't possible right now. So testing it out and exploring what it can do is impossible right now.
I just found that code written in static classes are easier to maintain and harder to make a mess in.
One of the biggest issues I've seen in all the legacy software I've worked in is that (for many many reasons) people will make a mess of a class.
Too many global properties, too many things going on in a method etc. etc.

Because any property in a static class is also static, you will learn very fast not to do this.
This means that everything that happens in a method, can only be done with the parameters that are being passed in.
This also means that the programmer will see very clearly that a method is doing too much, that a model is necessary instead of a bunch of parameters etc. (a model or a instantiated interface for dependency injection).
It will force the programmer (out of necessity) to write better code.
After implementing such a code setup you will see that some classes are only gonna be used for workflow, meaning they don't need to be instantiated. Still you want to order the workflow in some way or make sure some methods are there, eventhough the class will not be instantiated.
I also found that this way of code setup allows you to really separate model from functionality. Because you also want inheritance, this 100% separation is not really possible or recomended right now. But if the inheritance could be done on static classes, this would then be an option.

I'm also very sorry I even talking about static interfaces and static abstract classes.
I've noticed that a lot of programmers are really upset even thinking or exploring the posibilities that static brings (or could bring).
It is not to upset programmers, it is just for better separation of purpose and long term maintenance (which is something that, asfar I have seen, is always a problem).

Thanks for al of you who are willing to even think about these possibilities.

WIth kind regards, Ingmar

[Limiana]

For me, static abstract classes inheritance would be mostly helpful for programmer himself to ensure that the structure of the class is being followed. Example: SomeClass1 and SomeClass2 provide an API to communicate with an external process.

public static class SomeClass1 : SomeClassBase
{
    public static override string ProcessName => "notepad.exe";
}

public static class SomeClass2 : SomeClassBase
{
    public static override string ProcessName => "calc.exe";
}

public abstract class SomeClassBase
{
    public static string ProcessName { get; } //must define process name

    public static void IsRunning()
    {
        //perform check whether the process is running
    }
}

This way, you make sure you haven't forgotten to declare a property required by code structure and you get a helpful method without having to copy-paste it into each class. Moreover, you can quickly get types inheriting from base type via reflection in order to generate some diagnostics output.
And of course you could already achieve it all via singletons. But! Singletons are less convenient to use and, in addition, they have quite big overhead that's unwanted if performance is "mission critical".