Design Classe - Classe de base avec générique

Question

Descendant

J'ai les classes suivantes

class GridBase 
    { 
    public object DataSource { get; set; } 
    } 

    class GenericGrid<T> : GridBase 
    { 
    public new T DataSource { get; set; } 
    } 

les deux classes de grille GridBase et générique peut être instancié et l'on peut descendre soit aussi bien. Est-ce considéré comme le moyen correct/accepté de mettre en œuvre une telle hiérarchie? Ou devriez-vous aller le mile supplémentaire et mettre en œuvre comme le

class GridBase 
    { 
    protected object dataSource; 
    public object DataSource { get { return dataSource; } set { dataSource = value; } } 
    } 

    class GenericGrid<T> : GridBase 
    { 
    public new T DataSource { get { return (T)dataSource; } set { dataSource = value; } } 
    } 

suivant est de même pour les classes non génériques lorsqu'une propriété est réintroduite dans un descendant, je suis juste en utilisant un exemple générique ici.

Une autre affaire et la question

abstract class SomeBase 
    { 
    protected abstract void DoSomething(); 
    } 

    class Child : SomeBase 
    { 
    protected override void DoSomething() 
    { 
     /* Some implementation here */ 
    } 
    } 

La situation ici est que le cadre « X » déclare UneBase vous permettant de définir vos propres descendants. Les classes qu'ils créent (au moment de l'exécution) puis descendent de votre classe (Child dans le cas présent). Cependant, ils n'appellent pas votre méthode DoSomething(), à partir de leur implémentation de DoSomething().

Pour leur part, ils ne peuvent pas appeler aveuglément base.Dosomething() soit parce que le cas typique est que la classe qu'ils génèrent normalement descend de SomeBase et puisque la méthode est abstraite qui n'est pas valide. (Personnellement, je n'aime pas ce comportement en C#).

Mais de toute façon, ce design est-il bon ou accepté, cela n'appelle pas base.xxx(), surtout quand l '"intention" semble contredire?

EDIT Du point de vue de la conception du cadre. Est-ce acceptable/acceptable que cela fasse ça? Sinon, comment serait-il conçu de manière à empêcher un tel cas ou mieux de communiquer leur intention (dans les deux cas).

Answer 1

La deuxième forme de l'héritage générique (coulée de l'attribut de classe de base) est plus correct car il ne viole pas Liskov Substitution Principle. Il est concevable qu'une instance de la classe générique soit transtypée en classe de base et que l'accès aux données via la classe de base pointe vers une propriété différente. Vous devrez garder les deux synchronisés afin que la classe dérivée soit substituable pour la classe de base.

Alternativement, vous pouvez implémenter une sorte de modèle de stratégie où la classe de base demande la propriété Data de la classe dérivée, afin d'éviter la downcasting maladroite. Voici ce que j'avais à l'esprit:

public class Base { 
    private readonly object m_Data; //immutable data, as per JaredPar suggestion that base class shouldn't be able to change it 

    publlic Base(object data) { 
    m_Data = data; 
    } 


    protected virtual object GetData() {return m_Data;} 

    public Object DataSource {get {return GetData();}} 
} 

public class Derived<T> : Base { 
    private T m_Data; 

    public Derived():base(null){} 
    protected override object GetData() {return m_Data;} 

    protected new T Data {return m_Data;} 
} 

En ce qui concerne la deuxième question, je suis sûr de bien comprendre la question. Cela ressemble au problème que vous rencontrez avec le framework qui n'appelle pas la méthode abstraite lorsqu'il génère un proxy lors de l'exécution, ce qui est toujours légal dans les classes abstraites, car le seul moyen d'exécuter ce code est une classe dérivée qui doit remplace la méthode abstraite.

Answer 2

je préférerais quelque chose comme ceci:

interface IGrid { 
    object DataSource { get; } 
} 

interface IGrid<T> { 
    T DataSource { get; } 
} 

public Grid : IGrid { 
    public object DataSource { get; private set; } 

    // details elided 
} 

public Grid<T> : IGrid<T> { 
    public T DataSource { get; private set; } 
    object IGrid.DataSource { get { return this.DataSource; } } 

    // details elided 
} 

Notez que je ne suis pas héritant de Grid.

Answer 3

Pour la DataSource question que je préfère le modèle suivant

abstract class GridBase { 
    public abstract object DataSource { get; } 
} 

class GenericGrid<T> : GridBase { 
    private T m_data; 

    public override object DataSource { 
    get { return m_data; } 
    } 
    public T DataSourceTyped { 
    get { return m_data; } 
    set { m_data = value; } 
    } 
} 

Raisons

• comportant l'élément GridBase.DataSource être accessible en écriture est de type dangereux. Il me permet de rompre le contrat de GenericGrid<T> en mettant la valeur à non-T instance
• Ceci est plus d'une question d'opinion, mais je n'aime pas l'utilisation de new car il confond souvent les utilisateurs. Je préfère le suffixe ~ Type "pour ce scénario
• Ceci nécessite seulement que les données soient stockées une fois
• Ne nécessite pas de coulée non sûre.

EDIT OP corrigé que GridBase et GenericGrid sont les deux types utilisables

Dans ce cas je vous dire besoin de reconsidérer votre conception un peu. Les avoir tous les deux en tant que types utilisables vous ouvre à des erreurs de type très faciles à exposer.

GenericGrid<int> grid = new GenericGrid<int>(); 
GridBase baseGrid = grid; 
baseGrid.DataSource = "bad"; 
Console.Write(grid.DataSource); // Error!!! 

La conception sera beaucoup plus fiable si séparer le stockage de l'accès des valeurs d'une manière comme mon échantillon original. Vous pouvez étendre plus loin avec le code suivant pour un utile contenant non générique

class Grid : GridBase { 
    private objecm m_data; 
    public override object DataSource { 
    get { return m_data; } 
    } 
    public object DataSourceTyped { 
    get { return m_data; } 
    set { m_data = value; } 
    } 

}