20. marts 2009 - 23:11Der er
8 kommentarer og 1 løsning
I tvivl om forskellige collection klasser
Hej, jeg er ved at teste en funktion, som jeg ikke selv har lavet og er løbet ind i et mindre problem.
Jeg har en klasse, som har en List<string> collection. I den klasse findes en funktion, som returnerer indholdet af List<string> klassen i en ICollection<string> collection. Efter et hurtigt kig på MSDN dokumentationen kunne jeg læse mig frem til følgende:
public class List<T> : IList<T>, ICollection<T>, IEnumerable<T>, IList, ICollection, IEnumerable
Da C# ikke understøtter multiarv går jeg ud fra at List<T> klassen arver ovenstående interfaces. Vil der så ikke blive smidt information væk af den ene eller anden art, hvis jeg returnerer indholdet i en ICollection<T> collection?
Man kan sagtens komme ud for at miste data ved at caste mellem forskellige typer. Følgende er et simpelt eksempel på det.
#include <iostream> using namespace std;
int main() { float x = 4.15234; cout << (float)((int)x); }
Polymorphi er desuden ingen garanti for at der ikke går data tabt. Hvis man først begynder at caste sine pointers til void pointers kan der gå mange ting galt, hvis man ikke er opmærksom.
Det jeg ønsker at vide er, hvorvidt der er begrænsninger i forhold til at jeg returnerer fra list containeren ind i en collection container. Jeg er godt klar over at der ikke sker typekonvertering på indholdet da begge containers benytter sig af templates, men er der alligevel noget jeg skal være opmærksom på? Jeg går ud fra at der er en grund til at man returnerer indholdet af list ind i en ICollection? Hvilke fordele og ulemper kan være forbundet med det?
Første synes ikke du kan blande det sammen ... med at caste en float til int ... det er jo klart der går noget tabt, da du siger at alt efter kommaet skal smides væk ... 8 byte vs 4 byte.
Og igen ... ingen snakker om void pointers, det gør du. Der kan også være fejl i frameworket ... dette kan jo trækkes ud til verdens ende hvis man vil finde fejl ... men så er det jo bruger fejl du snakker om nu og ikke hvorvidt der er noget forkert i at gøre det.
Ingen ide om hvorfor han returnere en ICollection.
Brug af superklasse eller interface fremfor en klasse som enten extender eller implementerer taber aldrig data, da alle referencer stadig peger på det samme objekt i memory.
Der er to potentielle hovsaer: 1) eksplicitte interfaces og ikke virtual metoder med samme navn kan ændre opførsel 2) en conversion operator kan også lave alt muligt mærkeligt
En cast af en value type ændrer faktisk data og så kan der ske forskellige ting. Men det er noget andet.
Det anses ofte for værende god OOP skik at lade metoder returnere interfaces fremfor konkrete klasser, da det er langt mere fleksibelt til at ændre implementationen af metoden uden at bryde kontrakten. Måske finder du ud af at en LinkedList<> er smartere end en List<>.
"Det anses ofte for værende god OOP skik at lade metoder returnere interfaces fremfor konkrete klasser, da det er langt mere fleksibelt til at ændre implementationen af metoden uden at bryde kontrakten."
Okay, nu kan jeg godt se det smarte i det. Tak for hjælpen. Smid et svar.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
