a dinamikus a FrameWork 4.0 új funkciója. A dinamika megjelenése C#-nak egy gyenge nyelvtípus jellemzőit adta. A fordító már nem ellenőrzi a típust a fordítás idején, és a dinamikus objektum alapértelmezetten bármilyen kívánt funkciót támogat a fordítási idő alatt. Például, még ha nem is tudsz semmit a GetDynamicObject metódus által visszaadott objektumról, akkor is létrehozhatsz egy ilyen kódhívást, és a fordító nem jelent hibát:
A helyes használatnál először egy rossz használatra kell figyelni:
Az emberek gyakran használják a var kulcsszót a dinamikus összehasonlításhoz. Valójában a var és a dinamika teljesen két fogalom, és egyáltalán nem szabad összehasonlítani őket. A fordítás után a fordítási idő automatikusan egyezik a var változó tényleges típusával, és a változó deklarációját a tényleges típusra cseréli, ami úgy néz ki, mintha a tényleges típust hirdetnénk kódoláskor. A dinamika fordítása után valójában objektumtípus, de a fordító külön kezelést végez a dinamikus típussal, így nem végez típusellenőrzést a fordítás során, hanem a típusellenőrzést a futásidőben helyezi el.
Ez látható a Visual Studio szerkesztőablakában. A vars-ként beállított változók támogatják az "intelligens érzékelést", mert a Visual Studio képes következtetni a var típusok tényleges típusát, míg a dinamikusnak beállított változók nem támogatják az "intelligens érzékelést", mert a fordító semmit sem tud a futás típusáról. Az Intelligent Sense használata dinamikus változókhoz azt jelzi, hogy "Ez a művelet futásidőben megoldódik".
Az, hogy a dinamikus változó objektumváltozó, az IL kód ellenőrizhető, és az IL kód nem kerül közzétételre. Természetesen a fordító dinamikus deklarációkat is kezel, hogy megkülönböztesse a közvetlen objektumváltozókat.
A dinamikus funkció széles körben megjelenik az MSDN-ben az interoperabilitás egyszerűsítése érdekében, és úgy érzem, ezen alapozva értenek félre: mivel sok fejlesztő nem tudja, hogyan kell használni a COM+ és az OFFICE másodlagos fejlesztést, sürgősen dinamikus alkalmazási indokra van szükségük. Tehát a napi fejlesztésben úgy gondolom, hogy a dinamika értékes:
Típusátalakítás
A dinamikus típusú példányok és más példánytípusok közötti váltás egyszerű, és a fejlesztők könnyedén válthatnak a dynmic és nem dinamikus viselkedések között. Bármely példány implicit módon átalakítható dinamikus típusú példányokká, lásd az alábbi példát:
dinamikus d1 = 7;
dinamikus d2 = "egy string";
dinamikus d3 = System.DateTime.Today;
dinamikus d4 = System.Diagnostics.Process.GetProcesses();
Ezzel szemben az implicit átalakítás dinamikusan alkalmazható bármely típusdinamikus kifejezésre.
Fordítva, bármely típusdinamikus kifejezés implicit módon más típusokra is átalakítható.
int i = d1;
string str = d2;
DateTime dt = d3;
System.Diagnostics.Process[] procs = d4;
Túlterhelés problémája a dinamikus típusparaméterekkel a módszerben
Ha egy metódus egy dinamikus típusú objektumot passzol, vagy a hívott objektum dinamikus, akkor a túlterhelés megítélése futásidőben történik, nem fordításkor.
Dinamikus nyelvi futási idejű DLR
A dinamikus nyelvi futás ideje . A NET Framework 4 Beta 1 egy új API-készlet, amely támogatja a dinamikus típusokat C#-ban, és dinamikus programozási nyelveket is valósít meg, mint az IronPython és az IronRuby.
A dinamika leegyszerűsíti a tükröződéseket.
Korábban ilyen reflexiókat használtunk:
Most már egy egyszerűsített módja van az írásnak:
Lehet, hogy elutasítjuk ezt az egyszerűsítést, hiszen úgy tűnik, hogy a kódot nem csökkentették sokat, de ha figyelembe vesszük a hatékonyság és a szépség két jellemzőjét, akkor a dinamika előnyei nyilvánvalóak. A fordító optimalizálja a dinamikát sokkal gyorsabbra, mint a gyorsítótár nélküli visszaverődési hatékonyság. Ha összehasonlítani kell, futtathatod a fenti kettő kódját (az Add metódus rész hívja) 1000000-re, hogy következtetést vonj le.
|
Közzétéve 2016. 07. 07. 10:15:06
|
|
|
