|
|
Publisert på 07.07.2016 10:15:06
|
|
|
dynamisk er en ny funksjon i FrameWork 4.0. Fremveksten av dynamisk har gitt C# egenskapene til en svak språktype. Kompilatoren sjekker ikke lenger typen ved kompilering, og det dynamiske objektet støtter som standard alle funksjoner du ønsker under kompileringstiden. For eksempel, selv om du ikke vet noe om objektet som returneres av GetDynamicObject-metoden, kan du lage et kodekall som dette, og kompilatoren vil ikke rapportere en feil:
Når det gjelder korrekt bruk, bør én feil bruk påpekes først:
Folk bruker ofte nøkkelordet var for å sammenligne med dynamisk. Faktisk er var og dynamisk helt to begreper og bør ikke sammenlignes i det hele tatt. Når den er kompilert, matcher kompileringstiden automatisk den faktiske typen til var-variabelen og erstatter variabelens deklarasjon med den faktiske typen, noe som ser ut som om vi deklarerer den faktiske typen ved koding. Etter at dynamisk er kompilert, er det faktisk en objekttype, men kompilatoren vil gjøre en spesiell behandling av den dynamiske typen, slik at den ikke utfører noen typekontroll under kompilering, men legger typesjekken i kjøretiden.
Dette kan sees i redigeringsvinduet i Visual Studio. Variabler deklarert som var støtter "intelligent sense" fordi Visual Studio kan utlede den faktiske typen var-typer, mens variabler deklarert som dynamiske ikke støtter "intelligent sense" fordi kompilatoren ikke vet noe om typen på sin kjøretid. Ved å bruke Intelligent Sense for dynamiske variabler får du promptene "Denne handlingen vil bli løst under kjøring".
Det faktum at den dynamiske variabelen er en objektvariabel kan verifiseres av IL-koden, og IL-koden vil ikke bli publisert her. Selvfølgelig håndterer kompilatoren også dynamiske deklarasjoner for å skille mellom direkte objektvariabler.
dynamisk er mye gjengitt i MSDN for å forenkle interoperabilitet, og jeg føler at det er basert på dette at noen utviklere blir misforstått: fordi mange utviklere ikke vet hvordan de skal bruke koding som COM+ og OFFICE sekundærutvikling, trenger de akutt en dynamisk applikasjonsgrunn. Så i daglig utvikling mener jeg dynamikk er verdifullt:
Typekonvertering
Overgangen mellom dynamiske instanser og andre typer instanser er enkelt, og utviklere kan enkelt bytte mellom dynamiske og ikke-dynamiske atferder. Enhver instans kan implisitt konverteres til en dynamisk type instans, se følgende eksempel:
dynamisk d1 = 7;
dynamisk d2 = "en streng";
dynamisk d3 = System.DateTime.Today;
dynamisk d4 = System.Diagnostikk.Prosess.GetProcesses();
Omvendt kan en implisitt konvertering dynamisk anvendes på ethvert uttrykk av type dynamisk.
Og omvendt kan ethvert uttrykk av type dynamisk også implisitt konverteres til andre typer.
int i = d1;
streng str = d2;
DateTime dt = d3;
System.Diagnostics.Process[] procs = d4;
Overbelastningsproblem med dynamiske typeparametere i metoden
Hvis en metode kalles passerer et objekt av typen dynamisk, eller objektet som kalles er av typen dynamisk, skjer vurderingen av overbelastning under kjøring og ikke ved kompileringstid.
Dynamisk språkkjøretids-DLR
Den dynamiske språkkjøretiden er . NET Framework 4 Beta 1 er et nytt sett med API-er som støtter dynamiske typer i C# og også implementerer dynamiske programmeringsspråk som IronPython og IronRuby.
Dynamisk forenkler refleksjoner.
Tidligere brukte vi refleksjoner som dette:
Nå har vi en forenklet måte å skrive på:
Vi kan være avvisende til slik forenkling, tross alt virker det som om koden ikke har blitt mye redusert, men hvis vi tar hensyn til de to egenskapene effektivitet og skjønnhet, er fordelene med dynamikk åpenbare. Kompilatoren optimaliserer dynamisk for å være mye raskere enn ubufret refleksjonseffektivitet. Hvis du må sammenligne, kan du kjøre koden til de to ovennevnte (kallet Add-metoden) for 1000000 for å trekke en konklusjon.
|
Foregående:mvc henter JSON XML-dataene for innleggetNeste:En gjenkjenningsfeil oppsto. nær linje 1, kolonne 10
|
