Konwertuj List <DerivedClass> na List <BaseClass>

Chociaż możemy dziedziczyć po klasie bazowej / interfejsie, dlaczego nie możemy zadeklarować List<> używającej tej samej klasy / interfejsu?

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

Czy jest sposób?

Sposobem na wykonanie tej czynności jest iteracja listy i rzutowanie elementów. Można to zrobić za pomocą ConvertAll:

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

Możesz również użyć Linq:

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

Przede wszystkim przestań używać niemożliwych do zrozumienia nazw klas, takich jak A, B, C. Użyj zwierząt, ssaków, żyrafy, żywności, owoców, pomarańczy lub czegoś, w czym związki są jasne.

Twoje pytanie brzmi więc "dlaczego nie mogę przypisać listy żyraf do zmiennej listy typów zwierząt, skoro mogę przypisać żyrafę do zmiennej typu zwierzę?"

Odpowiedź brzmi: przypuśćmy, że możesz. Co mogło się wtedy nie udać?

Cóż, możesz dodać Tygrysa do listy zwierząt. Załóżmy, że pozwolimy ci umieścić listę żyraf w zmiennej, która zawiera listę zwierząt. Następnie próbujesz dodać tygrysa do tej listy. Co się dzieje? Czy chcesz, aby lista żyraf zawierała tygrysa? Chcesz awarię? czy chcesz, aby kompilator chronił Cię przed awarią, czyniąc przypisanie nielegalnym w pierwszej kolejności?

Wybieramy to drugie.

Ten rodzaj konwersji nazywa się konwersją „kowariantną”. W języku C # 4 umożliwimy Ci wykonanie kowariantnych konwersji na interfejsach i delegatach, gdy wiadomo, że konwersja jest zawsze bezpieczna . Zobacz moje artykuły na blogu na temat kowariancji i kontrawariancji, aby uzyskać szczegółowe informacje. (Będzie nowe na ten temat w poniedziałek i czwartek tego tygodnia).

Cytując wspaniałe wyjaśnienie Erica

Co się dzieje? Czy chcesz, aby lista żyraf zawierała tygrysa? Chcesz awarię? czy chcesz, aby kompilator chronił Cię przed awarią, czyniąc przypisanie nielegalnym w pierwszej kolejności? Wybieramy to drugie.

Ale co, jeśli chcesz wybrać awarię środowiska wykonawczego zamiast błędu kompilacji? Zwykle używałbyś Cast <> lub ConvertAll <>, ale wtedy będziesz miał 2 problemy: Utworzy kopię listy. Jeśli dodasz lub usuniesz coś z nowej listy, nie zostanie to odzwierciedlone na oryginalnej liście. Po drugie, występuje duży spadek wydajności i pamięci, ponieważ tworzy nową listę z istniejącymi obiektami.

Miałem ten sam problem i dlatego utworzyłem klasę opakowania, która może rzutować listę ogólną bez tworzenia zupełnie nowej listy.

W pierwotnym pytaniu możesz użyć:

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

a tutaj klasa wrapper (+ metoda rozszerzająca CastList dla łatwego użycia)

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

Jeśli IEnumerablezamiast tego użyjesz , zadziała (przynajmniej w C # 4.0, nie próbowałem wcześniejszych wersji). To tylko obsada, oczywiście, nadal będzie to lista.

Zamiast -

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

W oryginalnym kodzie pytania użyj -

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

O ile to nie działa, pomocne może być zrozumienie kowariancji i kontrawariancji .

Aby pokazać, dlaczego to nie powinno działać, oto zmiana w podanym kodzie:

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

     C FirstItem = DerivedList.First();
}

Czy to powinno działać? Pierwsza pozycja na liście jest typu „B”, ale typ elementu DerivedList to C.

Teraz załóżmy, że naprawdę chcemy stworzyć funkcję ogólną działającą na liście pewnego typu, która implementuje A, ale nie obchodzi nas, jaki to jest:

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

}

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

Możesz przesyłać tylko na listy tylko do odczytu. Na przykład:

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

I nie możesz tego zrobić dla list obsługujących zapisywanie elementów. Powodem jest:

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

Co teraz? Pamiętaj, że listObject i listString to w rzeczywistości ta sama lista, więc listString ma teraz element object - nie powinno to być możliwe i nie jest.

Osobiście lubię tworzyć biblioteki z rozszerzeniami klas

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

Ponieważ C # nie zezwala na tego typu dziedzictwokonwersja w tej chwili .

To rozszerzenie genialnej odpowiedzi BigJima .

W moim przypadku miałem NodeBaseklasę ze Childrensłownikiem i potrzebowałem sposobu na ogólne wyszukiwanie O (1) przez dzieci. Próbowałem zwrócić pole prywatnego słownika w getterze Children, więc oczywiście chciałem uniknąć kosztownego kopiowania / iteracji. Dlatego użyłem kodu Bigjima, aby rzutować na Dictionary<whatever specific type>rodzaj 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>();
    }
    ...
}

To działało dobrze. Jednak ostatecznie napotkałem niepowiązane ograniczenia i ostatecznie utworzyłem abstrakcyjną FindChild()metodę w klasie bazowej, która zamiast tego wykonywałaby wyszukiwania. Jak się okazało, wyeliminowało to przede wszystkim potrzebę korzystania z castingowego słownika. (Udało mi się go zastąpić prostym IEnumerabledo moich celów.)

Więc pytanie, które możesz zadać (zwłaszcza jeśli wydajność jest problemem uniemożliwiającym korzystanie z .Cast<>lub .ConvertAll<>) brzmi:

„Czy naprawdę muszę rzucić całą kolekcję, czy też mogę użyć metody abstrakcyjnej, aby zachować specjalną wiedzę potrzebną do wykonania zadania, a tym samym uniknąć bezpośredniego dostępu do kolekcji?”

Czasami najprostsze rozwiązanie jest najlepsze.

Możesz również użyć System.Runtime.CompilerServices.Unsafepakietu NuGet, aby utworzyć odwołanie do tego samego List:

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

Biorąc pod uwagę powyższy przykład, możesz uzyskać dostęp do istniejących Hammerinstancji na liście za pomocą toolszmiennej. Dodanie Toolinstancji do listy zgłasza ArrayTypeMismatchExceptionwyjątek, ponieważ toolsodwołuje się do tej samej zmiennej co hammers.

Przeczytałem cały ten wątek i chcę tylko zwrócić uwagę na coś, co wydaje mi się niespójne.

Kompilator uniemożliwia wykonanie przypisania za pomocą list:

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

Ale kompilator doskonale radzi sobie z tablicami:

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

Spór o to, czy zadanie jest znane jako bezpieczne, rozpada się tutaj. Zadanie, które wykonałem z tablicą, nie jest bezpieczne . Aby to udowodnić, jeśli podążę za tym:

myAnimalsArray[1] = new Giraffe();

Otrzymuję wyjątek czasu wykonywania „ArrayTypeMismatchException”. Jak to wyjaśnić? Jeśli kompilator naprawdę chce mi przeszkodzić w zrobieniu czegoś głupiego, powinien uniemożliwić mi przypisanie tablicy.