How to work around static methods in interfaces being disallowed | Tech Off

JChung2006

Let's suppose that I design an interface:

public interface IDoThis {
    void DoThis();
}

public class DoThis : IDoThis {
    void IDoThis.DoThis() {
        throw new NotImplementedException();
    }
}

I want to be able to expose a static factory method for all classes that implement this interface.

public interface IDoThis2 : IDoThis {
    static IDoThis CreateInstance(); // not allowed
}

public class DoThis2 : IDoThis2 {
    void IDoThis.DoThis() {
        throw new NotImplementedException();
    }
    static IDoThis CreateInstance() {
        return new DoThis2();
    }
}

How would you work around this apparent C# limitation? Or is this a wrong way to think about this, and, if so, how would you approach the problem?

Ion Todirel

how about using an abstract class? why is that method called CreateInstance, are all those classes supossed to be singletons?

dcuccia

Yeah - I've run up against that too. The only real work-arounds I see within an interface-based context are

create a static factory class+method that returns IDoThis objects (eg. based on an enumeration), or similarly
create a static generic factory class:
public static T CreateInstance<T>(Enum DoThisType) where T: IDoThis{...}

Can't enforce private constructors though (if you're interested in a singleton).

stevo_

Is this thread a joke? sorry if its not..

W3bbo

JChung2006 wrote:

How would you work around this apparent C# limitation? Or is this a wrong way to think about this, and, if so, how would you approach the problem?

It's not a limitation, it's how OOP works.

I recommend you read the GoF book "Design Patterns", it'll help demysterify a number of conventions and why-things-are-the-way-they-are thingies that often confuse beginners.

Anyway, the "workaround" is to use the Factory pattern.

JChung2006

Ion Todirel wrote:

how about using an abstract class? why is that method called CreateInstance, are all those classes supossed to be singletons?

They weren't supposed to be singletons, just regular instances.

This is not allowed:

public abstract class DoThisBase {
    public abstract void DoThis();
    public abstract static DoThisBase CreateInstance();
}

This is also not allowed:

public abstract class DoThisBase {
    public abstract void DoThis();
    public virtual static DoThisBase CreateInstance() {
        throw new NotImplementedException();
    }
}

This is allowed.

public abstract class DoThisBase {
    public abstract void DoThis();
    public static DoThisBase CreateInstance() {
        throw new NotImplementedException();
    }
}

But then, to override CreateInstance in an implementation, we must hide the base class' static method with the "new" modifier.

public class DoThisImpl : DoThisBase {
    public override void DoThis() {
    }
    public new static DoThisBase CreateInstance() {
        return new DoThisImpl();
    }
}

That defeats the purpose of putting the static method in the abstract base class though.

JChung2006

dcuccia wrote:

Yeah - I've run up against that too. The only real work-arounds I see within an interface-based context are

create a static factory class+method that returns IDoThis objects (eg. based on an enumeration), or similarly
create a static generic factory class:
public static T CreateInstance<T>(Enum DoThisType) where T: IDoThis{...}
Can't enforce private constructors though (if you're interested in a singleton).

I like the second idea! In fact, you can dispose with the enum.

public static class DoThisFactory {
    public static T CreateInstance<T>() where T : IDoThis, new() {
        return new T();
    }
}

Or

public static class Factory<S> {
    public static T CreateInstance<T>() where T : S, new() {
        return new T();
    }
}

Thank you! Smiley

JChung2006

W3bbo wrote:

JChung2006 wrote: How would you work around this apparent C# limitation? Or is this a wrong way to think about this, and, if so, how would you approach the problem?
It's not a limitation, it's how OOP works.

I recommend you read the GoF book "Design Patterns", it'll help demysterify a number of conventions and why-things-are-the-way-they-are thingies that often confuse beginners.

Anyway, the "workaround" is to use the Factory pattern.

I've read it. I know what the Factory pattern is.

P.S. It's "demystify," not "demysterify."

JChung2006

stevo_ wrote:

Is this thread a joke? sorry if its not..

It wasn't meant to be though looking at it again, it looks like I'm reinventing the constructor, isn't it? Maybe this is all rather silly. Unless I am missing something, there doesn't seem to be a way to specify constructor behavior in an interface.

evildictaitor

JChung2006 wrote:
dcuccia wrote:Yeah - I've run up against that too. The only real work-arounds I see within an interface-based context are

create a static factory class+method that returns IDoThis objects (eg. based on an enumeration), or similarly
create a static generic factory class:
public static T CreateInstance<T>(Enum DoThisType) where T: IDoThis{...}
Can't enforce private constructors though (if you're interested in a singleton).

I like the second idea! In fact, you can dispose with the enum.
public static class DoThisFactory {
    public static T CreateInstance<T>() where T : IDoThis, new() {
        return new T();
    }
}
Or
public static class Factory<S> {
    public static T CreateInstance<T>() where T : S, new() {
        return new T();
    }
}
Thank you!

But in order to use the factory CreateInstance method you need to qualify it with the closed form expression which is the type parameter for T, but if you know what type T should be, then why not just create a new instance of it directly there?

Interfaces work because I can pass around something knowing only that it fulfills a contract (e.g. IEnumerable), and can thus call the GetEnumerator() function on it regardless of the object's actual type because the compiler knows it has that function, because the object extends IEnumerator.

When it comes to static calls you no longer have the object being passed around. Your only mechanism of "getting" to the method you want to call is by knowing the type itself, but then having an interface is useless to you, because you can just call the type's method statically directly instead of using the interface. That's why interfaces don't have static methods.

JChung2006

In reply to evildictaitor

#Jun 1st @ 3:14 PM

What if an aspect of your contract is for its implementation to possess a method for creating new instances of itself in a way that can be accessed indirectly, via a delegate or a System.Func<T>, rather than directly via the constructor? It seems like you can't do this with an abstract class even, let alone an interface, unless I dig with System.Reflection and get a ConstructorInfo object. And you, of all people, know why I want to avoid doing that.