Comment Feed for How to work around static methods in interfaces being disallowed (TechOff on Channel 9)

Re: Re: How to work around static methods in interfaces being disallowed

JChung2006 — Tue, 03 Jun 2008 13:14:15 GMT

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.

Re: How to work around static methods in interfaces being disallowed

evildictaitor — Sun, 01 Jun 2008 22:14:29 GMT

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.

Re: How to work around static methods in interfaces being disallowed

JChung2006 — Sun, 01 Jun 2008 22:00:34 GMT

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.

Re: How to work around static methods in interfaces being disallowed

JChung2006 — Sun, 01 Jun 2008 21:51:39 GMT

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."

Re: How to work around static methods in interfaces being disallowed

JChung2006 — Sun, 01 Jun 2008 21:50:42 GMT

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();
    }
}

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

Thank you! :)

Re: How to work around static methods in interfaces being disallowed

JChung2006 — Sun, 01 Jun 2008 21:34:23 GMT

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.

Re: How to work around static methods in interfaces being disallowed

W3bbo — Sat, 31 May 2008 23:23:33 GMT

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.

Re: How to work around static methods in interfaces being disallowed

stevo_ — Sat, 31 May 2008 23:14:04 GMT

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

Re: How to work around static methods in interfaces being disallowed

dcuccia — Sat, 31 May 2008 22:58:00 GMT

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).

Re: How to work around static methods in interfaces being disallowed

Ion Todirel — Sat, 31 May 2008 22:38:48 GMT

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