Ich implementiere einen speziellen Fall eines unveränderlichen Wörterbuchs, das aus praktischen Gründen IEnumerable<KeyValuePair<Foo, Bar>> implementiert. Operationen, die normalerweise das Wörterbuch ändern würden, sollten stattdessen eine neue Instanz zurückgeben.
So weit, so gut. Aber wenn ich versuche, einen flüssigen Einheitentest für die Klasse zu schreiben, stelle ich fest, dass keine der beiden fließenden Assertion-Bibliotheken, die ich ausprobiert habe ( Should und Fluent Assertions ) unterstützt die NotBeSameAs() -Operation für Objekte, die IEnumerable implementieren - nicht, solange Sie sie nicht zuerst umsetzen zu Object .
Als ich zum ersten Mal mit Should darauf stieß, nahm ich an, dass es nur ein Loch im Framework war, aber als ich sah, dass Fluent Assertions dasselbe Loch hatte, dachte ich, dass ich relativ neu bin zu C #) Ich könnte etwas konzeptionell über C # Sammlungen vermissen - der Autor von sollte so viel impliziert , als ich mich anmeldete ein Problem.
Natürlich gibt es andere Möglichkeiten, dies zu testen - in Object umwandeln und NotBeSameAs() verwenden, einfach Object.ReferenceEquals verwenden, was auch immer - aber wenn es einen guten Grund dafür gibt, würde ich gerne wissen, was das ist ist.
Ein IEnumerable<T> ist nicht notwendigerweise ein reales Objekt. IEnumerable<T> garantiert, dass Sie über seine Zustände aufzählen können. In einfachen Fällen haben Sie eine Container-Klasse wie zB List<T> , die bereits materialisiert ist. Dann könnten Sie die Adressen beider Listen vergleichen. Ihr IEnumerable<T> kann jedoch auch auf eine Befehlsfolge verweisen, die beim Aufzählen ausgeführt wird. Grundsätzlich eine Zustandsmaschine:
Wenn Sie das in einer Variablen speichern, haben Sie kein vergleichbares Objekt (alles ist ein Objekt, also tun Sie das ... aber es ist nicht sinnvoll):
%Vor% Ihr Vergleich funktioniert nur für materialisierte ( .ToList() oder .ToArray() ) IEnumerables, da diese Statusmaschinen ausgewertet und ihre Ergebnisse in einer Sammlung gespeichert wurden. Also ja, die Bibliothek macht tatsächlich Sinn, wenn Sie wissen Sie IEnumerables materialisiert haben, müssen Sie dieses Wissen veröffentlichen, indem Sie sie auf Objekt übertragen und die gewünschte Funktion für dieses Objekt "manuell" aufrufen / p>
Außerdem, was Jon Skeet vorgeschlagen hat, werfen Sie einen Blick auf diesen Februar 2013 MSDN-Artikel von Ted Neward:
.NET Collections, Teil 2: Arbeiten mit C5
Unveränderbare (geschützte) Sammlungen
Mit dem Aufkommen von funktionalen Konzepten und Programmierstile, hat viel Betonung auf unveränderliche Daten geschwenkt und unveränderliche Objekte, vor allem, weil unveränderliche Objekte viel bieten Vorteile gegenüber Nebenläufigkeit und parallel Programmierung, sondern auch weil viele Entwickler unveränderliche Objekte leichter zu verstehen finden und Grund über. Folgerung aus diesem Konzept folgt dann dem Konzept von unveränderlichen Sammlungen - die Idee, dass unabhängig davon, ob die Objekte innerhalb der Sammlung sind unveränderlich, die Sammlung selbst ist behoben und nicht in der Lage, die Elemente in der ändern (hinzufügen oder entfernen) Sammlung. (Hinweis: Sie können eine Vorschau von unveränderbaren Sammlungen anzeigen veröffentlicht in NuGet im MSDN Base Class Library (BCL) Blog unter bit.ly/12AXD78 .)
Es beschreibt die Verwendung einer Open-Source-Bibliothek der Sammlung Güte namens C5. Schau dir Ссылка
anTags und Links c# collections equality fluent-assertions