Using dynamic type instead of none-possible generic properties

Question

Consider the following code:

    public dynamic DataGrid { get; private set; }
    public DataGridForm<TData, TGrid> GridConfig<TData, TGrid>() where TData : class
    {
        return DataGrid = new DataGridForm<TData, TGrid>();
    }

I'm trying to keep an instance of a generic class in a property for later usage, but as you know:

Properties, events, constructors etc can't be generic - only methods and types can be generic. Most of the time that's not a problem, but I agree that sometimes it's a pain (Jon Skeet)

I want to know is this a good way to round this situation?

Can't you put the common functionality in an Interface `IDataGridForm` and then have the property be of that type? — Corak, Jul 24 '13 at 13:33
Well, how do you want to *use* the `DataGridForm`? For example, I imagine you want to `display` a form. So make an Interface `IDataGridForm` with a method `Display()`. Now let your class `DataGridForm` implement that interface. It needs to have that `Display()` method to do that. Now have a property `public IDataGridForm DataGrid { get; private set; }`. This property can now contain a `DataGridForm` and you can `Display()` it wherever you want. — Corak, Jul 24 '13 at 13:42
Thanks for your reply, its seems this way is more better than using dynamic properties. — Saber Amani, Jul 24 '13 at 13:44
For more information about Interfaces (if needed) see: [MSDN](http://msdn.microsoft.com/library/vstudio/ms173156.aspx) — Corak, Jul 24 '13 at 13:48

lukegravitt · Accepted Answer · 2013-08-02T17:00:01.833

1

As the answer in the comment indicated, you can do this with a base class or an interface:

class DataGridForm {}
class DataGridForm<TData, TGrid> : DataGridForm {}

class GridConfigurator
{
    public DataGridForm DataGrid { get; private set; }
    public DataGridForm<TData, TGrid> GridConfig<TData, TGrid>() where TData : class
    {
        return DataGrid = new DataGridForm<TData, TGrid>();
    }
}

A ton of types and interfaces in C# were expanded this way when generics were added. However, I would probably re-evaluate your design so that perhaps whatever called GridConfig() was caching the DataGridForm since it knows the types. As an example, I do a very similar thing in my code:

class Vector<T> { ... }
static class Vector
{
    public static Vector<T> Create<T>(T value)
    {
        return new Vector<T>(value);
    }
}

class OtherClass
{
    public static Vector<int> MyVector = Vector.Create(1);
}

Your specific use case may not support this style though.

edited Aug 02 '13 at 17:00

answered Jul 26 '13 at 22:01

lukegravitt

892
4
12

I realized what you explained is not fit my requirements, what if I have to have a method in `DataGridForm` that returns `DataGridForm`. In this situation I've to make the base type a generic type too. Am I right? – Saber Amani Jul 27 '13 at 04:04
Not if it is a method, but yes if it is a property. In my 2nd example, Vector could inherit from Vector without issue. – lukegravitt Jul 29 '13 at 02:31
Shouldn't the return type of Vector.Create be Vector? – marcob Aug 02 '13 at 16:05
Yep, I fixed it just for you. :D – lukegravitt Aug 02 '13 at 17:00
Your property or method could return a DataGridForm which is an instance of DataGridForm. – Grax32 Aug 28 '13 at 16:56

score 0 · Answer 2 · answered Jul 31 '13 at 01:40

In this case your type itself has to be generic.

    class GridConfigurator<TData, TGrid>
       where TData : class
    {
        public DataGridForm<TData, TGrid> DataGrid { get; private set; }
        public DataGridForm<TData, TGrid> GridConfig<TData, TGrid>()
        {
            return DataGrid = new DataGridForm<TData, TGrid>();
        }
    }

But I don't understand the purpose of this class. The GridConfig method has a non-obvious side effect of setting the DataGrid property (which has a private setter). If I were using this class, I would never guess that the value that GridConfig() returns to me is also set as the DataGrid property. In other words:

var configurator = new GridConfigurator();
var firstGrid = configurator.GridConfig();
var firstReference = configurator.DataGrid;
var secondGrid = configurator.GridConfig();
var secondReference = configurator.DataGrid;

I would assume the following would return false:

object.ReferenceEquals(firstGrid, secondGrid);

But I would assume this would return true:

object.ReferenceEquals(firstReference, secondReference);

Because at no point in the above code do I ever assign the DataGrid property. It is not clear that a method called GridConfig() would have that effect.

Making the enclosing type (GridConfigurator) also generic seems to defeat the purpose of what you're trying. Why would anyone use this type when they could just use a direct reference to DataGridForm instead?

If the GridConfig method is supposed to do something more than just assign a new default instance of DataGridForm, then make it a static factory class like this:

static class GridConfigurator
{
  public static DataGridForm<TData,TGrid> GridConfig<TData, TGrid>(...) where TData: class
  {
    var grid = new DataGridForm<TData,TGrid>();
    // do something with the parameters to this method to initialize the instance.
     return grid;
  }
}

I would also name the method something other than GridConfig. Like Configure() or Create().

Using dynamic type instead of none-possible generic properties

2 Answers2