Generic Polymorphism - Strange Behavior

Pluggable framework

Imagine a simple pluggable system that's pretty straightforward using inheritance polymorphism:

• We have a graphics rendering system.
• There are various types of graphic shapes (monochrome, color, etc.) that need to be rendered
• Rendering is done by a data-specific plugin like. The ColorRenderer will display the ColorShape.
• Each plugin implements IRenderer
  
  , so they can all be saved in IRenderer[]
  
  .
• At startup, IRenderer[]
  
  populated with a series of individual renderers
• When data for a new form is received, a plugin based on the form type is selected from the array.
• The plugin is then called by calling its method Render
  
  , passing in the form as the base type.
• The method is Render
  
  overridden in every descendant class; it returns the form back to its offspring and then displays it.

Hope this is clear. I think this is a fairly common setting. Very easy with inheritance polymorphism and runtime casting.

Execution without quotes

Now for the tricky part. In response to this question, I wanted to come up with a way to do it without casting. It is difficult because of this array IRenderer[]

, to get a plugin from an array you usually had to cast it to a specific type in order to use its type specific methods and we cannot do that. Now we can work around this by interacting with the plugin only with its base classes, but part of the requirement was that a type-specific method must be run for the renderer, in which a data packet of a particular type is used as an argument, and the base class cannot do this. because there is no way to pass it a type-specific data packet without dropping it to the base and then back to the ancestor. Tricky.

At first I thought it was not possible, but after several tries I found I could do it by blaming the C # generic system. I create an interface that is contravariant to both the plugin and the form type, and then I used that. The renderer resolution is determined by the type. Xyzzy, the contravariant interface makes the cast unnecessary.

Here is the shortest version of the code I could give as an example. This will compile and work correctly:

public enum ColorDepthEnum { Color = 1, Monochrome = 2 }

public interface IRenderBinding<in TRenderer, in TData> where TRenderer : Renderer 
                                                  where TData: Shape  
{ 
    void Render(TData data);
}
abstract public class Shape
{
    abstract public ColorDepthEnum ColorDepth { get; }
    abstract public void Apply(DisplayController controller);
}

public class ColorShape : Shape
{
    public string TypeSpecificString = "[ColorShape]";  //Non-virtual, just to prove a point
    override public ColorDepthEnum ColorDepth { get { return ColorDepthEnum.Color; } }

    public override void Apply(DisplayController controller)
    {
        IRenderBinding<ColorRenderer, ColorShape> renderer = controller.ResolveRenderer<ColorRenderer, ColorShape>(this.ColorDepth);
        renderer.Render(this);
    }
}
public class MonochromeShape : Shape
{
    public string TypeSpecificString = "[MonochromeShape]";  //Non-virtual, just to prove a point
    override public ColorDepthEnum ColorDepth { get { return ColorDepthEnum.Monochrome; } }

    public override void Apply(DisplayController controller)
    {
        IRenderBinding<MonochromeRenderer, MonochromeShape> component = controller.ResolveRenderer<MonochromeRenderer, MonochromeShape>(this.ColorDepth);
        component.Render(this);
    }
}


abstract public class Renderer : IRenderBinding<Renderer, Shape>
{
    public void Render(Shape data) 
    {
        Console.WriteLine("Renderer::Render(Shape) called.");
    }
}


public class ColorRenderer : Renderer, IRenderBinding<ColorRenderer, ColorShape>
{

    public void Render(ColorShape data) 
    {
        Console.WriteLine("ColorRenderer is now rendering a " + data.TypeSpecificString);
    }
}

public class MonochromeRenderer : Renderer, IRenderBinding<MonochromeRenderer, MonochromeShape>
{
    public void Render(MonochromeShape data)
    {
        Console.WriteLine("MonochromeRenderer is now rendering a " + data.TypeSpecificString);
    }
}


public class DisplayController
{
    private Renderer[] _renderers = new Renderer[10];

    public DisplayController()
    {
        _renderers[(int)ColorDepthEnum.Color] = new ColorRenderer();
        _renderers[(int)ColorDepthEnum.Monochrome] = new MonochromeRenderer();
        //Add more renderer plugins here as needed
    }

    public IRenderBinding<T1,T2> ResolveRenderer<T1,T2>(ColorDepthEnum colorDepth) where T1 : Renderer where T2: Shape
    {
        IRenderBinding<T1, T2> result = _renderers[(int)colorDepth];  
        return result;
    }
    public void OnDataReceived<T>(T data) where T : Shape
    {
        data.Apply(this);
    }

}

static public class Tests
{
    static public void Test1()
    {
       var _displayController = new DisplayController();

        var data1 = new ColorShape();
        _displayController.OnDataReceived<ColorShape>(data1);

        var data2 = new MonochromeShape();
        _displayController.OnDataReceived<MonochromeShape>(data2);
    }
}

      

        
        
        
      

    

If you run Tests.Test1()

, the output will be:

ColorRenderer is now rendering a [ColorShape]
MonochromeRenderer is now rendering a [MonochromeShape]

      

        
        
        
      

    

Beautiful, she works, right? Then I wondered ... what if it ResolveRenderer

returned the wrong type?

Safe type?

According to this MSDN article ,

Contravariance, on the other hand, seems to be inconsistent ... It seems laggy, but it is type-safe code that compiles and runs. The code is type safe because T specifies the type of the parameter.

I think it is actually not safe.

Introducing an error that returns the wrong type

So, I introduced an error to the controller, so it mistakenly stores the ColorRenderer where the MonochromeRenderer belongs, like this:

public DisplayController()
{
    _renderers[(int)ColorDepthEnum.Color] = new ColorRenderer();
    _renderers[(int)ColorDepthEnum.Monochrome] = new ColorRenderer(); //Oops!!!
}

      

        
        
        
      

    

I thought I would get some kind of type mismatch exception. But no, the program ends, with a mysterious exit:

ColorRenderer is now rendering a [ColorShape]
Renderer::Render(Shape) called.

      

        
        
        
      

    

What...?

My questions:

Firstly,

Why did you MonochromeShape::Apply

call Renderer::Render(Shape)

? It tries to call Render(MonochromeShape)

, which obviously has a different method signature.

The code inside the method MonochromeShape::Apply

only has a reference to the interface, in particular IRelated<MonochromeRenderer,MonochromeShape>

, which only provides Render(MonochromeShape)

.

Although Render(Shape)

it looks similar, it is a different method with a different entry point and is not even used in the interface being used.

Secondly,

Since none of the methods Render

are virtual (each descendant type introduces a new, not virtual, not overridden method with a different type-specific argument), I would have thought the entry point was compile-time related. Are prototypes of methods within a method group actually selected at runtime? How is it possible to work without VMT for sending? Does it use some kind of reflection?

Thirdly,

C # contravariance is definitely not safe? Instead of invalidating the exception (which at least tells me there is a problem), I get unexpected behavior. Is there a way to detect such problems at compile time, or at least make them throw an exception instead of doing something unexpected?