Convertir la liste <DerivedClass> en liste <BaseClass>

Alors que nous pouvons hériter de la classe / interface de base, pourquoi ne pouvons-nous pas déclarer un List<> utilisant la même classe / interface?

interface A
{ }

class B : A
{ }

class C : B
{ }

class Test
{
    static void Main(string[] args)
    {
        A a = new C(); // OK
        List<A> listOfA = new List<C>(); // compiler Error
    }
}

Y a-t-il un moyen de contourner?

La façon de faire ce travail consiste à parcourir la liste et à convertir les éléments. Cela peut être fait en utilisant ConvertAll:

List<A> listOfA = new List<C>().ConvertAll(x => (A)x);

Vous pouvez également utiliser Linq:

List<A> listOfA = new List<C>().Cast<A>().ToList();

Tout d'abord, arrêtez d'utiliser des noms de classe impossibles à comprendre comme A, B, C.Utilisez Animal, Mammifère, Girafe, Nourriture, Fruit, Orange ou quelque chose où les relations sont claires.

Votre question est alors "pourquoi ne puis-je pas attribuer une liste de girafes à une variable de type liste d'animal, puisque je peux attribuer une girafe à une variable de type animal?"

La réponse est: supposons que vous puissiez. Qu'est-ce qui pourrait alors mal tourner?

Eh bien, vous pouvez ajouter un tigre à une liste d'animaux. Supposons que nous vous permettions de mettre une liste de girafes dans une variable contenant une liste d'animaux. Ensuite, vous essayez d'ajouter un tigre à cette liste. Ce qui se produit? Voulez-vous que la liste des girafes contienne un tigre? Voulez-vous un crash? ou voulez-vous que le compilateur vous protège du plantage en rendant l'attribution illégale en premier lieu?

Nous choisissons ce dernier.

Ce type de conversion est appelé une conversion «covariante». En C # 4, nous vous autoriserons à effectuer des conversions covariantes sur les interfaces et les délégués lorsque la conversion est connue pour être toujours sûre . Voir les articles de mon blog sur la covariance et la contravariance pour plus de détails. (Il y en aura un nouveau sur ce sujet le lundi et le jeudi de cette semaine.)

Pour citer la grande explication d'Eric

Ce qui se produit? Voulez-vous que la liste des girafes contienne un tigre? Voulez-vous un crash? ou voulez-vous que le compilateur vous protège du plantage en rendant l'attribution illégale en premier lieu? Nous choisissons ce dernier.

Mais que faire si vous souhaitez choisir un crash d'exécution au lieu d'une erreur de compilation? Vous utiliseriez normalement Cast <> ou ConvertAll <> mais alors vous aurez 2 problèmes: Cela créera une copie de la liste. Si vous ajoutez ou supprimez quelque chose dans la nouvelle liste, cela ne sera pas reflété dans la liste d'origine. Et deuxièmement, il y a une grosse pénalité en termes de performances et de mémoire car cela crée une nouvelle liste avec les objets existants.

J'ai eu le même problème et j'ai donc créé une classe wrapper qui peut lancer une liste générique sans créer une liste entièrement nouvelle.

Dans la question d'origine, vous pouvez alors utiliser:

class Test
{
    static void Main(string[] args)
    {
        A a = new C(); // OK
        IList<A> listOfA = new List<C>().CastList<C,A>(); // now ok!
    }
}

et ici la classe wrapper (+ une méthode d'extension CastList pour une utilisation facile)

public class CastedList<TTo, TFrom> : IList<TTo>
{
    public IList<TFrom> BaseList;

    public CastedList(IList<TFrom> baseList)
    {
        BaseList = baseList;
    }

    // IEnumerable
    IEnumerator IEnumerable.GetEnumerator() { return BaseList.GetEnumerator(); }

    // IEnumerable<>
    public IEnumerator<TTo> GetEnumerator() { return new CastedEnumerator<TTo, TFrom>(BaseList.GetEnumerator()); }

    // ICollection
    public int Count { get { return BaseList.Count; } }
    public bool IsReadOnly { get { return BaseList.IsReadOnly; } }
    public void Add(TTo item) { BaseList.Add((TFrom)(object)item); }
    public void Clear() { BaseList.Clear(); }
    public bool Contains(TTo item) { return BaseList.Contains((TFrom)(object)item); }
    public void CopyTo(TTo[] array, int arrayIndex) { BaseList.CopyTo((TFrom[])(object)array, arrayIndex); }
    public bool Remove(TTo item) { return BaseList.Remove((TFrom)(object)item); }

    // IList
    public TTo this[int index]
    {
        get { return (TTo)(object)BaseList[index]; }
        set { BaseList[index] = (TFrom)(object)value; }
    }

    public int IndexOf(TTo item) { return BaseList.IndexOf((TFrom)(object)item); }
    public void Insert(int index, TTo item) { BaseList.Insert(index, (TFrom)(object)item); }
    public void RemoveAt(int index) { BaseList.RemoveAt(index); }
}

public class CastedEnumerator<TTo, TFrom> : IEnumerator<TTo>
{
    public IEnumerator<TFrom> BaseEnumerator;

    public CastedEnumerator(IEnumerator<TFrom> baseEnumerator)
    {
        BaseEnumerator = baseEnumerator;
    }

    // IDisposable
    public void Dispose() { BaseEnumerator.Dispose(); }

    // IEnumerator
    object IEnumerator.Current { get { return BaseEnumerator.Current; } }
    public bool MoveNext() { return BaseEnumerator.MoveNext(); }
    public void Reset() { BaseEnumerator.Reset(); }

    // IEnumerator<>
    public TTo Current { get { return (TTo)(object)BaseEnumerator.Current; } }
}

public static class ListExtensions
{
    public static IList<TTo> CastList<TFrom, TTo>(this IList<TFrom> list)
    {
        return new CastedList<TTo, TFrom>(list);
    }
}

Si vous utilisez à la IEnumerableplace, cela fonctionnera (au moins en C # 4.0, je n'ai pas essayé les versions précédentes). Ce n'est qu'un casting, bien sûr, ce sera toujours une liste.

Au lieu de -

List<A> listOfA = new List<C>(); // compiler Error

Dans le code d'origine de la question, utilisez -

IEnumerable<A> listOfA = new List<C>(); // compiler error - no more! :)

Quant à savoir pourquoi cela ne fonctionne pas, il pourrait être utile de comprendre la covariance et la contravariance .

Juste pour montrer pourquoi cela ne devrait pas fonctionner, voici une modification du code que vous avez fourni:

void DoesThisWork()
{
     List<C> DerivedList = new List<C>();
     List<A> BaseList = DerivedList;
     BaseList.Add(new B());

     C FirstItem = DerivedList.First();
}

Cela devrait-il fonctionner? Le premier élément de la liste est de type "B", mais le type de l'élément DerivedList est C.

Maintenant, supposons que nous voulons vraiment juste créer une fonction générique qui opère sur une liste d'un type qui implémente A, mais nous ne nous soucions pas de quel type c'est:

void ThisWorks<T>(List<T> GenericList) where T:A
{

}

void Test()
{
     ThisWorks(new List<B>());
     ThisWorks(new List<C>());
}

Vous ne pouvez diffuser que des listes en lecture seule. Par exemple:

IEnumerable<A> enumOfA = new List<C>();//This works
IReadOnlyCollection<A> ro_colOfA = new List<C>();//This works
IReadOnlyList<A> ro_listOfA = new List<C>();//This works

Et vous ne pouvez pas le faire pour les listes qui prennent en charge l'enregistrement des éléments. La raison en est:

List<string> listString=new List<string>();
List<object> listObject=(List<object>)listString;//Assume that this is possible
listObject.Add(new object());

Et maintenant? Rappelez-vous que listObject et listString sont la même liste en fait, donc listString a maintenant un élément objet - cela ne devrait pas être possible et ce n'est pas le cas.

J'aime personnellement créer des bibliothèques avec des extensions aux classes

public static List<TTo> Cast<TFrom, TTo>(List<TFrom> fromlist)
  where TFrom : class 
  where TTo : class
{
  return fromlist.ConvertAll(x => x as TTo);
}

Parce que C # n'autorise pas ce type de héritageconversion pour le moment .

Ceci est une extension de la réponse brillante de BigJim .

Dans mon cas, j'avais une NodeBaseclasse avec un Childrendictionnaire, et j'avais besoin d'un moyen de faire des recherches génériques O (1) à partir des enfants. J'essayais de renvoyer un champ de dictionnaire privé dans le getter de Children, donc évidemment je voulais éviter une copie / itération coûteuse. Par conséquent, j'ai utilisé le code de Bigjim pour convertir le Dictionary<whatever specific type>en un générique Dictionary<NodeBase>:

// Abstract parent class
public abstract class NodeBase
{
    public abstract IDictionary<string, NodeBase> Children { get; }
    ...
}

// Implementing child class
public class RealNode : NodeBase
{
    private Dictionary<string, RealNode> containedNodes;

    public override IDictionary<string, NodeBase> Children
    {
        // Using a modification of Bigjim's code to cast the Dictionary:
        return new IDictionary<string, NodeBase>().CastDictionary<string, RealNode, NodeBase>();
    }
    ...
}

Cela a bien fonctionné. Cependant, j'ai finalement rencontré des limitations indépendantes et j'ai fini par créer une FindChild()méthode abstraite dans la classe de base qui ferait les recherches à la place. Il s'est avéré que cela a éliminé le besoin du dictionnaire coulé en premier lieu. (J'ai pu le remplacer par un simple IEnumerablepour mes besoins.)

La question que vous pourriez vous poser (surtout si les performances sont un problème qui vous interdit d'utiliser .Cast<>ou .ConvertAll<>) est:

"Ai-je vraiment besoin de convertir toute la collection, ou puis-je utiliser une méthode abstraite pour détenir les connaissances spéciales nécessaires pour effectuer la tâche et éviter ainsi d'accéder directement à la collection?"

Parfois, la solution la plus simple est la meilleure.

Vous pouvez également utiliser le System.Runtime.CompilerServices.Unsafepackage NuGet pour créer une référence au même List:

using System.Runtime.CompilerServices;
...
class Tool { }
class Hammer : Tool { }
...
var hammers = new List<Hammer>();
...
var tools = Unsafe.As<List<Tool>>(hammers);

Compte tenu de l'exemple ci-dessus, vous pouvez accéder aux Hammerinstances existantes dans la liste à l'aide de la toolsvariable. L'ajout d' Toolinstances à la liste lève une ArrayTypeMismatchExceptionexception car fait toolsréférence à la même variable que hammers.

J'ai lu tout ce fil et je veux juste souligner ce qui me semble être une incohérence.

Le compilateur vous empêche de faire l'affectation avec les listes:

List<Tiger> myTigersList = new List<Tiger>() { new Tiger(), new Tiger(), new Tiger() };
List<Animal> myAnimalsList = myTigersList;    // Compiler error

Mais le compilateur est parfaitement bien avec les tableaux:

Tiger[] myTigersArray = new Tiger[3] { new Tiger(), new Tiger(), new Tiger() };
Animal[] myAnimalsArray = myTigersArray;    // No problem

L'argument de savoir si l'affectation est connue pour être sûre s'effondre ici. La mission que j'ai faite avec le tableau n'est pas sûre . Pour le prouver, si je continue avec ceci:

myAnimalsArray[1] = new Giraffe();

J'obtiens une exception d'exécution "ArrayTypeMismatchException". Comment l'expliquer? Si le compilateur veut vraiment m'empêcher de faire quelque chose de stupide, il aurait dû m'empêcher de faire l'affectation du tableau.