创建接口子类的实例

Question

I have interface and 3 classes that derives it, but how use 1 variable for each one type?

  public interface IBuilder<T> where T: System.IConvertible{}

  public class SimpleBuilder :  IBuilder<SimpleCollagePatterns>{}

  public class CreativeBuilder : IBuilder<CreativeCollagePatterns>{}

  public class ShapeBuilder : IBuilder<ShapeCollagePatterns>{}

And I need create instance of class when it`s necessary

I have IBuilder<IConvertible> currentBuilder variable, but I cannot create instance of any Builder

this.currentBuilder = new SimpleBuilder(); //Doesn`t work

Only if I change IBuilder<IConvertible> currentBuilder to IBuilder<SimpleCollagePatterns> currentBuilder or atother type I can create this type of Builder, but I need to have abulity create any type

Answer 1

I faced the same scenario. But ended up to find there is no solution for this. It is not possible to create object of any type in run time. As you said, changing IBuilder currentBuilder to IBuilder currentBuilder is the only way to create object for SimpleBuilder type. Similarly for other cases.

Answer 2

If you really want to use one variable for all scenarios, you can always define it as a simple object to hold on to the instance and use the IS operator to see which type it really is when necessary like this:

if (this.currentBuilder is SimpleBuilder) { }

Answer 3

我相信你需要让你的IBuilder协变，请参阅https://msdn.microsoft.com/en-us/library/dd997386(v=vs.110).aspx

public interface IBuilder<out T>

Answer 4

What you want to read about is called covariance , which is denoted by keyword out beside a generic type parameter in the interface declaration.

public interface IBuilder<out T> where T: System.IConvertible{}

This will allow you to declare a variable of type IBuilder<IConvertible> and assign eg. SimpleBuilder to it, you just need to be aware of what consequences applying covariance has, the most important being, in plain words, generic type can only be used as return type of the type members.

If you can't change the IBuilder interface - there is no option to create a variable for all cases.

For further info you can research SO, eg. Difference between Covariance & Contra-variance or read at the source, eg. https://msdn.microsoft.com/en-us/library/mt654055.aspx .

Answer 5

If you don't need public access to the generic type

In particular if SimpleCollagePatterns is used exclusivly by the class that implements that particular interface (In this case ShapeBuilder ), then you don't need covariance .

There is a simple design pattern that relies on inheritance alone.

For example:

public interface IBuilder {
    void Build();
}

public interface IBuilder<T> : IBuilder {
    T BuildParameter {get;}
}

Note: The BuildParameter corresponds to your BuildCollagePattern

Then you can implement the interface as such:

public class SpecificBuilder : IBuilder<Int32> {
    // The specific constructor
    public SpecificBuilder(int param) { BuildParameter = param; }

    // Implement from IBuilder
    public void Build() {
        System.Console.WriteLine("Building with Int32: " + BuildParameter);
    }

    // Implement from IBuilder<T>
    public Int32 BuildParameter {get; private set;}
}

Then you can pass around any IBuilder<T> as an IBuilder

public class Program {
    public static void Main() {
        SpecificBuilder builder = new SpecificBuilder(42);

        // SpecificBuilder implements IBuilder<Int32>
        // Build accepts any IBuilder
        // So this is legal:
        Build(builder);
    }

    //
    // Note this method accepts anything that inherits from IBuilder
    // 
    public static void Build(IBuilder builder) {

        builder.Build();

        // If you'd need access to the BuildParameter of IBuilder<T>
        // then this pattern fails you here.
        // Unless of course you want to check for types and cast
    }
}

As noted before: Once you need access to the generic type outside of the class thats implementing the IBuilder<T> you'd need to start differentiating types and cast them accordingly. Not so elegant.

But you can design lot's of stuff this way and maintain extensibility. I bring this up, as I have used this pattern to implement image filters myself and your BuildCollagePattern might be very much realizable with this design pattern.