Namenskonventionen für C # -Methoden: ToSomething vs. AsSomething


82

Als ich einige Erweiterungsmethoden für meine Geschäftslogikobjekte schrieb, kam ich zu der Frage, die Konvertierungsmethoden umzubenennen. someObject.ToAnotherObject()würde gut mit dem weit verbreiteten gehen object.ToString().

Allerdings verwechselt LINQ zum Beispiel beide Varianten und ich kann keinen Unterschied zwischen ihnen feststellen. ToDictionary(), ToList(), AsParallel(), AsQueryable(), ...

Was sind die Unterschiede zwischen diesen beiden Namenskonventionen und was sollte ich wissen, um zu entscheiden, ob ich sie für meine eigenen Klassen verwenden möchte?

Antworten:


91

ToDictionaryund ToListwerden vorangestellt, Toweil sie nicht unbedingt die strukturelle Identität der ursprünglichen Sammlung oder ihrer Eigenschaften bewahren.

  • Durch die Umwandlung von a List<T>in a Dictionary<K, V>wird eine Sammlung mit einer völlig neuen Struktur erstellt.
  • Durch die Umwandlung von a HashSet<T>in a List<T>wird die Eindeutigkeitseigenschaft von Mengen entfernt.

Methoden, denen ein Präfix vorangestellt ist As, führen keines dieser Dinge aus - sie bieten lediglich eine alternative Ansicht der ursprünglichen Sammlung. Sie bereichern es.


41
Also, auf einem Apfel könnte ich anrufen, .AsCleanApple()da ich ihn nur waschen muss und .ToFruitSalad()weil mein Messer die Struktur des Apfels verändern würde
Physikbuddha

3
@Physikbuddha Grundsätzlich ja.
MKII

37
@Physikbuddha Es scheint mir , wie AsCleanApplewird ändern etwas über den Apfel. Eine bessere Analogie könnte seinAsFruit
dcastro

4
.AsCleanAppleSource()würde etwas, das eine Quelle für Äpfel war, in etwas verwandeln, das eine Quelle für saubere Äpfel war; Wenn nötig, einen Waschschritt hinzufügen, aber vielleicht nichts tun, waren die Äpfel bereits als sauber bekannt. .ToPunnet()würde auf diese Quelle zugreifen und Ihnen ein Körbchen Äpfel geben.
Jon Hanna

2
Dies ist nicht unbedingt der Fall, aber im Allgemeinen können Sie sich "AsXXX ()" als Besetzung und "ToXXX ()" als Konvertierung vorstellen.
Nateirvin

26

In Linq führen ToXXXalle Methoden die Abfrage aus und erstellen aus den Ergebnissen ein neues Objekt, während die AsXXXMethoden eine neue Abfrage erstellen, die sich in irgendeiner Weise unterscheidet. Es kann das gleiche Objekt, sondern durch eine andere Schnittstelle zugegriffen wird ( AsEnumerable()tut dies) oder es kann ein neues Objekt sein , dass Abspaltungen die Funktionalität (die anderen Methoden , um dies zu tun, auch wenn einige überprüfen, ob sie nur das angegebene Objekt zurückgeben, zB AsQueryable()werden zurückgeben, sourcewenn es IQueryable<T>bereits implementiert ist , oder EnumerableQuery<TElement>andernfalls ein neues erstellen ).


that alters how the functionality- Ist das howunnötig oder sollte es einen nächsten Teil der Erklärung geben?
Kapol

@Kapol nein, nur ein Tippfehler, der durch gleichzeitiges Komponieren und Tippen verursacht wird.
Jon Hanna

Ich denke, dies ist die richtige Antwort, dh eine aktive versus statische Projektion der ursprünglichen Instanz. ToXXX()projiziert die Daten ohne Beziehung zum Original. AsXXX()behält eine aktive Beziehung zum Original bei (zumindest in den Beispielen für Aufzählung / Abfrage, die wir diskutieren).
Tim Medora

+1 für ToXXX execute the queryund AsXXX produce a new query. Klingt richtig nach dem, was ich auf LINQ gelesen habe, und MSDN scheint für ToXXX zu bestätigen , aber ich frage mich, ob jemand eine Quelle dafür hat, ob alle AsXXX Methoden verzögert ausgeführt werden?
Brichins

1
@brichins gibt es sogar eine sinnvolle Möglichkeit, "alle" zu sagen, da jeder von uns einen neuen Anbieter mitbringen könnte, der zusätzlich AsXXXzu den Linq- Anbietern einen neuen hinzufügt (z. B. den AsParallelvon PLinq hinzugefügten, den AsNoTrackingvon Entity Framework bereitgestellten). und so weiter). Sicherlich ist der Kern von linq das, was durch Queryableund definiert ist Enumerable, und diese beiden Klassen folgen beide dieser Konvention. Die meisten Ergänzungen tun dies in dem Maße, in dem "alles" wahrscheinlich korrekt wäre, aber es ist zu offen, um garantiert immer korrekt zu sein (obwohl ich jeden Bruch als Konstruktionsfehler betrachten würde).
Jon Hanna
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.