03. december 2003 - 16:58Der er
36 kommentarer og 1 løsning
Hjælp til .NET/C# rapport
Hejsa...
Jeg har lavet et C# program og er nu igang med at skrive en rapport dertil...
MEN der er noigle forskellige ting, jeg har spg. til...så jeg håber MEGET i kan hjælpe mig!
1. I min C# bog står der : "CLR miljøet omfatter en enklere programmeringsmodel, sikkerhed, understøttelse med stærke værktøjer og hjælp ved ibrugtagning, håndtering af pakker og anden support. Endelig omfatter miljøet .Net Frameworks de funktioner, der normalt ligger i runtime-biblioteker plus et par nye".
Mit spg. hertil - alt i CLR er vel klasser, ik?
2. Hvad er fordelen/årsagen til, at man caster et objekt af en klasse som implementerer et givet interface til selve interface-typen.
Nedenfor har jeg prøvet at forklare, hvordan jeg selv tror det hænger sammen - så jeg håber i kan bekræfte mig i dette!? :)
Ved brug af ”normale” interfaces : Brugeren kan kalde metoderne i klassen, som er def. i interfacet direkte! Dvs. her har brugeren af klassen, valgmuligheden om han vil kalde div. metoder direkte eller om han vil simplificere objektet/caste til interfacetypen og dermed kun have adgang til de metoder i klassen, som er defineret i det interface klassen implementerer.
Eksplicit implementering af interfaces: Det at et objekt først skal castes til et givet interface ved eksplicit implementering, kan benyttes til at skjule selve implementeringen af et interface i en given klasse. Her kan metoderne i klassen, som er def. i interfacet ikke tilgås direkte! Dvs. her har brugeren ikke noget valg omkring hvordan han vil tilgå diverse metoder( i klassen som er def. i interfacet), de kan nemlig kun tilgås hvis han caster objektet til interfacetypen.
Derudover har brugeren heller ikke adgang(i nogle af de 2 tilfælde) til resten af klassen(konstruktøren) og det vil derfor ikke være muligt, at oprette nye instanser heraf eller at oprette flere medlemmer(metoder) i klassen.
3. I min C# bog står der : "Desuden indfører C# begrebet ”Struct”, hvilke tillader brugeren at implementerer letvægtsobjekter, som ikke bliver allokeret på heapen."
mit spg. hertil er : Hvordan skal "Letvægsobjekter" forstås? og hvad er forskellen på ordet "Heapen" og "Stakken"?? De ér begge abstrationer - ik?
4. I min C# bog står der : "Ved hjælp anderledes brug af begreber, som boxing og unboxing, forbinder C# primitive typer og klasser, idet sproget tillader hvilken som helst datatype at blive behandlet som et objekt".
Hvad betyder det rent funktionelt, samt teknisk set?? Jeg må indrømme, jeg har ikke forstået hvordan følgende skal tolkes, samt hvorfor det er smart/nødvendigt?
Her må i meget gerne komme med et kode eksempel og god en detaljeret forklaring.
5. I min C# bog står der : "Når en værditype(struct) castes til et interface bliver værditypen boxed og interface-pointeren en den boxede værdi."
Kan i skære dette lidt mere ud for mig?-)
Håber MEGET I kan hjælpe mig!!! Opgaven skal meget snart afleveres!
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Den store fordel ved det er ar resten af koden kun kan bruge metoderne fra IX men ikke andre metoder som er i X. Det betyder nemlig at man kan erstatte den ene linie med:
IX x = new X2();
(hvor X2 også implementerer IX) uden at bekymre sig for om nogen har brugt metoder i X som ikke er i X2.
class MainClass { public static void Main(string[] args) { double x = 123.456; string s = x.ToString(); Console.WriteLine(s); } }
I Java skal man:
public class Box { public static void main(String[] args) { double x = 123.456; // det her virke rikke i Java: // String s0 = x.toString(); // det her er eksplicit konvertering fra double til Double: Double xx = new Double(x); String s1 = xx.toString(); System.out.println(s1); } }
class MainClass { public static void Main(string[] args) { Double xx = 123.456; double x = xx; Console.WriteLine(x); } }
public class Unbox { public static void main(String[] args) { Double xx = new Double(123.456); // kan ikke lade sig gøre i Java: // double x = xx; // det her er eksplicit konvertering fra Double til double: double x = xx.doubleValue(); System.out.println(x); } }
2a. Jeg har brug for at vide, om det er rigtigt, det jeg har skrevet i spg. 2?
2b. Du skrev til spg. 2 : "...uden at bekymre sig for om nogen har brugt metoder i X som ikke er i X2."...øøhm? forstår ikke helt hvad du mener med : "uden at bekymre sig.."??
3a. Er det smarte, at man uden videre kan gemme 2 forskellige instanser fra hver sin klasse i én fælles type variable(pga. de begge iml. interfacet), hvis det er - hvorfor så?
3. Hvorfor er der forskel på overhead størrelsen?
4. Eks.1 :Point start = new Point(5,5); Console.WriteLine("Start: {0}, start");
I min bog står der "" I C# og CLR-verdenen er der lidt magi der sørger for at værdityper ligner referencetyper, og denne form hedder "boxing". Som al anden magi er det ret simpelt. Ved kaldet til Console.WriteLine() leder sompileren efter en måde at konvertere start til typen object på fordiden anden parametertil WriteLine() skal have typen object. Ved en referencetype(fx class) er det let eftersom object er stamklasse for alle klasser. Compileren overfører simpelthen en objektreference der refererer til instansen af klassen. Der er imidlertid ingen referencer i forbindelse med en værdiklasse, så C# compileren allokerer en "referencetypekasse" til punktet, markerer at den indeholder en Point og kopierer værdien deraf ind i kassen. Nu er det en referencetype, og vi kan behandle den som et objekt. Denne reference overføres så til funktionen WriteLine() som kalder funktionen ToString() med det boxede Point, og programmet skriver : Start: (5,5)
Eks. 2:
int value = 15; DataTime date = new DateTime(); Console.WriteLine("Value,Date: {0}{1}", value, date);
I dette eksempel bliver både value og date boxed, når WriteLine kaldes.
Jeg skal kunne forstå princippeet i boxing/unboxing og dermed kunne kom et eksempel...Men jeg føler stadig ikke - at jeg har fået fat i den dybere liggende logik i dette...? hvorfor det er smart/nødvendigt??
Der er findes imidlertid ingen referencer i forbindelse med structs. For at forstå, hvad det betyder i denne sammenhæng(mit projekt), så lad os se på det kode, hvor jeg har benyttet structs.
Vare ms = new Vare(); ms.antal = … ms.pris = …
I de ovenstående tre linie kode, sker der følgende :
C# kompileren allokerer en referencetypeklasse, markerer at den indeholder en Vare og bagefter tilføjes/kopiere diverse værdier ind i klassen. Nu er det en referencetype, og man kan behandle den ligesom object.
Er dette rigtigt at skrive? Når man alligevel skal indpakke/boxe en struct så man kan ref. til den, hvori ligger så fordelen i at bruge den i forhold til en klasse?
ja...okey...men...du har stadig ikke svaret på : "Når man alligevel skal indpakke/boxe en struct så man kan ref. til den, hvori ligger så fordelen i at bruge den i forhold til en klasse?"...Man kan jo ikke bruge den til noget sålænge man ikke kan ref. til den...eller?
Lad os forestille os at interface X har to metoder A og B, class X1 implementerer X og har metoderne A, B og C og class X2 implementerer X og har metoderne A, B og D.
Hvis man brugte:
X1 x = new X();
så kunne man i koden bruge metoden x.C() og hvis man fik lyst til at skifte implementering så vill eman skulle ind og rette alle de steder fordi X2 ikke har C.
Hvis man bruger:
X x = new X1();
så ved man at man kan erstatte det med:
X x = new X2();
fordi medmindre nogen explicit har griset med ((X1)x).C(), så skal kode virke uden ændringer fordi interfacet er det samme.
øøh...er det mig der ikke kan følge med...eller? hvad for du ud af "X1 x = new X();" du lægger en interfacetype over i en klassetype (og ikke omvendt)?
ok...hvordan ville du beskrive de 3 linier kode i mit indlæg fra kl. 21:05:35...samt forklar mig lige, hvad fordelen er med structs er, når man alligevel skal lave dem om til. referencer for at kunne benytte dem...!??
Beklager...men jeg er stadig ikke helt med på dit indlæg fra kl. 21:19:18
X1 x = new X1(); //Så nu har vi adgang til metode A,B og C!
så kunne man i koden bruge metoden x.C() og hvis man fik lyst til at skifte implementering så vill eman skulle ind og rette alle de steder fordi X2 ikke har C.
Beklager...men jeg er stadig ikke helt med på dit indlæg fra kl. 21:19:18
X1 x = new X1(); //Så nu har vi adgang til metode A,B og C!
Jeg forstår ikke hvad du mener med dette : "...hvis man fik lyst til at skifte implementering så ville man skulle ind og rette alle de steder fordi X2 ikke har C."??
X x = new X1(); //Her har man adgang til metoderne A & B
X x = new X2(); //og så overskriver du x med det samme igen?
Jeg benytter indsætter diverse oprettede struct i anden kolonne i en SortedList og i første kolonne placeres en string...
dvs...
foreach(bla bla bla) { Vare ms = new Vare(); ms.antal = bla bla; ms.pris = bla bla; oprettedeVarer.Add(sVare,ms); }
Hvordan optræder mine structs her? som referencer eller ...? det gør de vel? Dvs. når jeg skriver "Vare ms = new Vare();" har jeg blot oprettet en struct men INGEN ref.?
foreach(bla bla bla) { Vare ms = new Vare(); // opretter en værdi type ms.antal = bla bla; ms.pris = bla bla; oprettedeVarer.Add(sVare,ms); // her konverteres den til en referance type fordi Add skal bruge et objekt }
der må være noget basalt jeg endnu ikke har forstået?? :)
jeg kan godt forstår at man a1 2004 har adgang til metoderne A,B og C og i a1 2005 har adgang til metoderne A,B og D...og at man dermed ikke længere har adgang til metode C i 2005...MEN jeg forstår ikke hvad a2 hjælper når man kun har adgang til metoderne A og B i både 2004 og 2005...?
Vi forudsætter at der ikke er et reelt behov for C eller D.
X med A og B definerer det der er nødvendigt til at løse opgaven.
En af ideerne med et interface er at man kan skifte implementation uden at at det påvirker koden.
Hvis nu X2 A og B kører 10 gange hurtigere end X1 A og B så vil der være en stor fordel ved at skifte.
Problemet er hvis der skal rettes i meget kode. Det koster penge.
Med alternativ 2 kan det ikke lade sig gøre. Man vil få compile fejl, hvis C forsøges brugt.
Med alternativ 1 kan man være 80% sikker på, at hvis der er andre end den oprindelige programmør der har rettet i koden, så er metode C pludselig blevet brugt til et eller andet.
Og pludeslig er koden bundet til implementationen ikke interfacet.
jeg er sgu stadig ikke med...i hvert fald ikke på det tekniske plan...
altså...man har en klasse X1 og en klasse X2 som begge impl. X som indeholder metoderne A og B.
Når du snakker om at ændre implementering(fx pga. det kommet til at kører hurtigere) er det så fra en tredie Klasse X3 fx eller hvad? Hvis man fx i X3 oprettede en ny instans af X1(X1 x = new X1()) så man kunne kalde metoderne A og B direkte...hvis man pludselig ville skifte til metoderne i X2 kunne man blot ændre X1 x = new X1() til X2 x = new X2() (selvfølgelig KUN hvis metoderne i begge klasser hedder det samme!!) eller er jeg helt forkert på den???
Hvorfor skal man rundt og ændre mange steder i koden, hvis man ikke har lavet det via interfaces?
Problemet er at hvis det er muligt (fordi man har en X1), så er der en eller anden programmør der vil bruge metode C 777 gange i koden. Når man så skal skifte fra X1 til X2, så skal man ind og rette de 777 steder hvor C er brugt. Hvis man bruger X så kan folk ikke kalde C. Og derfor er det uproblematisk at skifte fra X1 til X2.
ja det kan jeg forstår! :) det har jeg faktisk hele tiden forstået...Jeg troede din løsning med interfacet og var svar på problematikken med de forskellige metoder(C,D) fra hver sig klasse!!
Det er forståeligt, at hvis begge klasser imp. det samme interface og der dermed KUN benyttes de samme metoder...så KAN der ikke opstå problemer...
Næh - det er såmænd er rimeligt trivielt eksempel på encapsulation.
Synes godt om
Ny brugerNybegynder
Din løsning...
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.
