dynamischen Typ anstelle von keiner möglichst generischen Eigenschaften

Question

den folgenden Code vor:

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

Ich versuche, in einem property zur späteren Verwendung eine Instanz einer generischen Klasse zu halten, aber wie Sie wissen:

Eigenschaften, Ereignisse, Konstruktoren usw. können nicht generisch sein - nur Methoden und Typen können generisch sein. Die meiste Zeit ist das kein Problem, aber ich zustimmen, dass es manchmal ein Schmerz (Jon Skeet)

ich wissen will, ist dies ein guter Weg, um diese Situation zu runden?

Answer 1

Wie die Antwort im Kommentar angegeben ist, können Sie dies mit einer Basisklasse oder einer Schnittstelle:

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

Eine Tonne Typen und Schnittstellen in C# auf diese Weise erweitert wurde, als Generika wurde hinzugefügt. Allerdings würde ich wahrscheinlich Ihr Design neu bewerten, so dass vielleicht alles, was GridConfig() genannt wurde, das DataGridForm zwischenspeichert, da es die Typen kennt. Als ein Beispiel, ich mache eine sehr ähnliche Sache in meinem Code:

Ihr spezifischer Anwendungsfall unterstützt möglicherweise diesen Stil nicht.

Answer 2

In diesem Fall muss Ihr Typ selbst generisch sein.

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

Aber ich verstehe nicht den Zweck dieser Klasse. Die GridConfig-Methode hat einen nicht offensichtlichen Nebeneffekt beim Festlegen der DataGrid-Eigenschaft (die über einen privaten Setter verfügt). Wenn ich diese Klasse verwenden würde, würde ich niemals vermuten, dass der Wert, den GridConfig() mir zurückgibt, auch als DataGrid-Eigenschaft festgelegt ist. Mit anderen Worten:

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

würde ich folgendes würde return false annehmen:

object.ReferenceEquals(firstGrid, secondGrid); 

Aber ich würde davon ausgehen, das wahr zurückkehren würde:

object.ReferenceEquals(firstReference, secondReference); 

Da zu keinem Zeitpunkt in den obigen Code zuweisen ich jemals die DataGrid-Eigenschaft. Es ist nicht klar, dass eine Methode namens GridConfig() diesen Effekt haben würde.

Den einschließenden Typ (GridConfigurator) auch generisch zu machen scheint den Zweck dessen, was Sie versuchen, zu besiegen. Warum sollte jemand diesen Typ verwenden, wenn er stattdessen nur einen direkten Verweis auf DataGridForm verwenden könnte?

Wenn die GridConfig Methode soll etwas mehr tun, als nur eine neue Standardinstanz von DataGridForm zuweisen, dann machen es eine statische Factory-Klasse wie folgt aus:

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

ich auch das Verfahren etwas anderes nennen würde als GridConfig. Wie Configure() oder Create().