dynamisk er en ny funktion i FrameWork 4.0. Fremkomsten af dynamisk har givet C# karakteristika for en svag sprogtype. Kompilatoren tjekker ikke længere typen ved kompilering, og det dynamiske objekt understøtter som standard enhver funktion, du ønsker, under kompileringstiden. For eksempel, selvom du ikke ved noget om objektet, som GetDynamicObject-metoden returnerer, kan du lave et kodekald som dette, og compileren vil ikke rapportere en fejl:
Når det gælder korrekt brug, bør én forkert brug først påpeges:
Folk bruger ofte nøgleordet var til at sammenligne med dynamisk. Faktisk er var og dynamisk fuldstændig to begreber og bør slet ikke sammenlignes. Når den er kompileret, matcher kompileringstiden automatisk den faktiske type af var-variablen og erstatter variablens deklaration med den faktiske type, hvilket ser ud som om, vi erklærer den faktiske type ved kodning. Efter dynamisk kompilering er det faktisk en objekttype, men compilatoren vil foretage en særlig behandling af den dynamiske type, så den ikke udfører nogen typekontrol under kompileringen, men placerer typekontrollen i runtime.
Dette kan ses i editor-vinduet i Visual Studio. Variabler erklæret som vars understøtter "intelligent sense", fordi Visual Studio kan udlede den faktiske type var-typer, mens variabler erklæret som dynamiske ikke understøtter "intelligent sense", fordi compileren intet ved om typen af sin runtime. Ved brug af Intelligent Sense til dynamiske variabler vises prompt: "Denne handling vil blive løst ved kørsel".
Det faktum, at den dynamiske variabel er en objektvariabel, kan verificeres af IL-koden, og IL-koden vil ikke blive offentliggjort her. Selvfølgelig håndterer compileren også dynamiske deklarationer for at skelne mellem direkte objektvariabler.
dynamisk er bredt gengivet i MSDN for at forenkle interoperabiliteten, og jeg føler, at det er på baggrund af dette, at nogle udviklere bliver misforstået: fordi mange udviklere ikke ved, hvordan man bruger kodning som COM+ og OFFICE sekundær udvikling, har de akut brug for en dynamisk applikationsbegrundelse. Så i den daglige udvikling mener jeg, at dynamik er værdifuldt:
Typekonvertering
Overgangen mellem dynamiske instanser og andre typer instanser er simpel, og udviklere kan nemt skifte mellem dynamiske og ikke-dynamiske adfærdsfunktioner. Enhver instans kan implicit 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.Diagnostik.Proces.GetProcess();
Omvendt kan en implicit konvertering dynamisk anvendes på ethvert udtryk af typen dynamisk.
Og omvendt kan ethvert udtryk af typen dynamisk også implicit konverteres til andre typer.
int i = d1;
streng str = d2;
DateTime dt = d3;
System.Diagnostics.Process[] procs = d4;
Overbelastningsproblem med dynamiske typeparametre i metoden
Hvis en metode kaldes passerer et objekt af typen dynamisk, eller det objekt, der kaldes, er af typen dynamisk, så sker vurderingen af overbelastning under kørsel og ikke ved kompileringstidspunktet.
Dynamisk sprog-runtime DLR
Den dynamiske sprog-runtime er . NET Framework 4 Beta 1 er et nyt sæt API'er, der understøtter dynamiske typer i C# og også implementerer dynamiske programmeringssprog som IronPython og IronRuby.
Dynamik forenkler refleksioner.
Tidligere brugte vi refleksioner som denne:
Nu har vi en forenklet måde at skrive på:
Vi kan være afvisende over for en sådan forenkling, for det ser ud til, at koden ikke er blevet reduceret meget, men hvis vi tager de to karakteristika effektivitet og skønhed i betragtning, er fordelene ved dynamisk åbenlyse. Kompilatoren optimerer dynamisk til at være meget hurtigere end ucachet refleksionseffektivitet. Hvis du skal sammenligne, kan du køre koden fra de to ovenstående (kaldet Add-metoden) for 1000000 for at drage en konklusion.
|
Opslået på 07/07/2016 10.15.06
|
|
|
