Zrozumienie zmiennych i typów danych w C#

Różnica między Dynamic a Var

W C# var jest używane dla lokalnych zmiennych z niejawnie określonym typem, gdzie typ jest ustalany w czasie kompilacji, co zapewnia bezpieczeństwo typów i wsparcie dla IntelliSense. W przeciwieństwie dynamic pozwala zmiennym omijać sprawdzanie typów w czasie kompilacji, z typem określanym w czasie wykonania, oferując większą elastyczność, ale z ryzykiem błędów w czasie wykonania i obniżoną wydajnością.

Tim Corey wyjaśnia, że var zapewnia bezpieczeństwo typów dzięki określaniu typu w czasie kompilacji jako statyczne zmienne, podczas gdy dynamic oferuje elastyczność przy rozpoznawaniu typów w czasie wykonania, co może prowadzić do błędów w czasie wykonania i problemów z wydajnością.

// Declaration of a dynamic variable that can change types at runtime
dynamic testDynamic;

// Declaration of a dynamic variable that can change types at runtime
dynamic testDynamic;

// This will result in a compile-time error due to lack of type inference
// var testVar;

// This will result in a compile-time error due to lack of type inference
// var testVar;

// var assignment with type inference from the initial value
var testVar = 2; // testVar is inferred to be of type int

// var assignment with type inference from the initial value
var testVar = 2; // testVar is inferred to be of type int

// Attempting to change the type from int to double causes an error
// testVar = 1.1; // Error: Cannot implicitly convert type 'double' to 'int'

// Attempting to change the type from int to double causes an error
// testVar = 1.1; // Error: Cannot implicitly convert type 'double' to 'int'

// Another example with dynamic typing
var testVar = 2.1; // Now testVar is a double

// Another example with dynamic typing
var testVar = 2.1; // Now testVar is a double

// Declaring a constant variable
const int MaxValue = 100;

// Declaring a constant variable
const int MaxValue = 100;

Dynamiczna automatyczna konwersja typów

Tim podkreśla, jak słowo kluczowe dynamic pozwala na elastyczne operowanie typami, działając trochę jak object, ale z dodatkowymi możliwościami. O 3:53 Tim demonstruje, jak dynamic może bezproblemowo konwertować pomiędzy różnymi typami podczas wykonywania, pokazując zdolność do obsługi obliczeń zawierających liczby całkowite i podwójne bez jawnego rzutowania, jak pokazano w jego przykładzie kodu:

// Demonstrating dynamic type conversion at runtime
dynamic testDynamic = 1;
testDynamic = testDynamic + 2.1;
Console.WriteLine(testDynamic); // Outputs 3.1 as it converts the integer to a double

// Demonstrating dynamic type conversion at runtime
dynamic testDynamic = 1;
testDynamic = testDynamic + 2.1;
Console.WriteLine(testDynamic); // Outputs 3.1 as it converts the integer to a double

Tutaj, Tim (4:39) ilustruje, że testDynamic początkowo przechowuje wartość całkowitą, ale bez trudu konwertuje ją na podwójną, gdy dodaje do niej 2.1, co skutkuje wyjściem 3.1.

Pomimo swojej elastyczności, Tim ostrzega przed nadmiernym stosowaniem dynamic z powodu kosztów wydajności wynikających z częstych konwersji typów. Podkreśla o 5:55, że dynamic powinno być używane oszczędnie w rozwoju C#, aby uniknąć niepotrzebnego obciążenia procesora i utraty sprawdzania typów w czasie kompilacji oraz wsparcia IntelliSense, co jest kluczowe dla utrzymania odpornych i bezbłędnych baz kodu.

Wady Dynamic in Development

Tim Corey ilustruje, jak dynamic może prowadzić do błędów w czasie wykonania i nieoczekiwanego zachowania w twoich aplikacjach. Zaczyna od pokazania, jak zadeklarować zmienną dynamiczną i przypisać jej początkowo pusty ciąg znaków, aby uniknąć natychmiastowego błędu. Następnie próbuje wywołać nieistniejącą metodę sayHi na zmiennej dynamicznej, co nie powoduje błędu w czasie kompilacji, ale skutkuje wyjątkiem w czasie wykonania, demonstrując kluczową wadę dynamic: brak sprawdzania w czasie kompilacji.

// Demonstrating lack of compile-time checks with dynamic
dynamic testDynamic = "";
// testDynamic.sayHi(); // Runtime error: method does not exist

// Demonstrating lack of compile-time checks with dynamic
dynamic testDynamic = "";
// testDynamic.sayHi(); // Runtime error: method does not exist

Ponadto o godz. 8:38 Tim pokazuje, w jaki sposób zmienne dynamiczne mogą zmieniać typy w czasie wykonywania, co może powodować nieoczekiwane zachowanie. Przypisuje obiekt Person do zmiennej dynamicznej, następnie przypisuje jej wartość tekstową i pokazuje, jak ta elastyczność może prowadzić do błędów logicznych i utrudniać debugowanie.

// Demonstrating the potential errors with dynamic type reassignment
dynamic testDynamic = new Person();
testDynamic = "Hi";
Console.WriteLine(testDynamic); // Works fine, but not ideal for type safety

// Demonstrating the potential errors with dynamic type reassignment
dynamic testDynamic = new Person();
testDynamic = "Hi";
Console.WriteLine(testDynamic); // Works fine, but not ideal for type safety

Tim wyjaśnia również, że zmienne dynamiczne nie są obsługiwane przez IntelliSense, co może prowadzić do błędów wykonania spowodowanych literówkami lub nieprawidłowymi nazwami metod. Na przykład, o 14:05, wywołuje nazwę właściwości Email, która nie istnieje, podkreślając, jak ten błąd pozostaje niezauważony aż do czasu wykonania. Kod kompiluje się bez błędów, ale zawodzi podczas wykonywania, gdy metody lub właściwości oczekiwane na obiekcie Person nie zostają znalezione na tekście.

// Demonstrating a runtime error due to missing property
// testDynamic.Email = "Test@test.com"; // property not found until runtime

// Demonstrating a runtime error due to missing property
// testDynamic.Email = "Test@test.com"; // property not found until runtime

// Using var for strongly-typed assignments
var testVar = new Person();
testVar.FirstName = "Sue";
testVar.LastName = "Storm";

// The use of IntelliSense assists in reducing runtime errors
Console.WriteLine(testVar.SayHello()); // Ideally a method in Person class

// Using var for strongly-typed assignments
var testVar = new Person();
testVar.FirstName = "Sue";
testVar.LastName = "Storm";

// The use of IntelliSense assists in reducing runtime errors
Console.WriteLine(testVar.SayHello()); // Ideally a method in Person class

// Attempting to change type results in compile-time errors with var
// testVar = "Hi"; // Compile-time error

// Attempting to change type results in compile-time errors with var
// testVar = "Hi"; // Compile-time error

// Method returning a dynamic type
public dynamic GetMessage() {
    return "This is a test";
}

// Method returning a dynamic type
public dynamic GetMessage() {
    return "This is a test";
}

Dłączego i kiedy używać Dynamic

Tim omawia konkretne scenariusze, w których dynamic staje się niezbędny. Wyjaśnia on, że C# jest zasadniczo językiem silnie typowanym, co oznacza, że każdej zmiennej przypisany jest określony typ, który pozostaje niezmienny przez cały jej cykl życia. Stanowi to kontrast w stosunku do języków takich jak JavaScript, w których zmienne mogą dynamicznie zmieniać typy.

Tim, o godz. 18:14, wyjaśnia, że chociaż język C# jest zaprojektowany z myślą o zmiennych silnie typowanych, istnieją sytuacje, zwłaszcza podczas interakcji z systemami zewnętrznymi lub językami takimi jak Python, Ruby lub obiektami COM, w których typowanie dynamiczne może być korzystne. Używa przykładu integracji z Python API, aby podkreślić praktyczną potrzebę stosowania dynamic. W takich przypadkach posiadanie elastycznego systemu typów, który może dostosować się do różnych typów danych z zewnętrznych źródeł, upraszcza interakcję.

Tim Corey o 18:44 podkreśla, że choć dynamic jest użyteczne do interakcji między językami, na ogół nie jest zalecane dla kodu czystego C# z powodu utraty sprawdzania błędów w czasie kompilacji i wsparcia dla IntelliSense. Ostrzega, że elastyczność dynamic wiąże się z kosztami wydajności i bezpieczeństwa typów, czyniąc go mniej pożądanym wyborem do regularnego programowania w C#, gdzie preferowane powinny być silnie typowane zmienne.

Dłączego i kiedy używać słowa kluczowego Var

Tim następnie omawia użycie i filozofię stojącą za słowem kluczowym var w C#. Zauważa, że istnieją dwa główne obozy, jeśli chodzi o użycie var: Ci, którzy wolą używać go wyłącznie, i ci, którzy wolą jawne deklaracje typów.

Tim, o 19:43, wyjaśnia, że zwolennicy var twierdzą, że zachęca to do lepszych konwencji nazewnictwa, czyniąc kod samodokumentującym się. Uważają oni, że nazwy zmiennych powinny być na tyle opisowe, aby przekazywały typ bez konieczności wyraźnej deklaracji.

Z drugiej strony (20:46) zwolennicy jawnych deklaracji typów argumentują, że widoczność rzeczywistego typu bezpośrednio w kodzie pozwala od razu rozpoznać, jaki jest typ zmiennej lokalnej, bez konieczności najeżdżania kursorem na zmienną w celu sprawdzenia jej typu. Na przykład:

// Explicit type declaration provides clarity
string firstName = "Tim";

// Explicit type declaration provides clarity
string firstName = "Tim";

Jest to preferowane przez niektórych, ponieważ usuwa wszelkie wątpliwości co do typu zmiennej.

Tim dzieli się swoim zrównoważonym podejściem o 21:15, stwierdzając, że zazwyczaj używa jawnych typów dla powszechnych typów danych jak string, int, double i decimal, ponieważ sprawia to, że kod jest bardziej przejrzysty i unika potencjalnych problemów, takich jak pomylenie double i decimal. Na przykład:

// Explicit type ensures there's no ambiguity between float types
double myMoney = 1.1; // This is a double
decimal myMoney = 1.1M; // This is a decimal

// Explicit type ensures there's no ambiguity between float types
double myMoney = 1.1; // This is a double
decimal myMoney = 1.1M; // This is a decimal

Tim podkreśla, że jawne deklarowanie typu zapewnia użycie właściwego typu, zwłaszcza gdy może dojść do zamieszania między podobnymi typami.

Jednak Tim również przyznaje, że var może być szczególnie przydatne, gdy mamy do czynienia z długimi lub skomplikówanymi typami. Podaje przykład o 23:37, gdzie deklaracja List<List<Person>> może być rozwlekła:

// Declaring a complex type using var
var rounds = new List<List<Person>>();

// Declaring a complex type using var
var rounds = new List<List<Person>>();

Demonstruje również jego użyteczność w pętlach foreach (23:55):

// Utilizing var in loop for cleaner code
foreach (var round in rounds) {
    // Do something with each round
}

// Utilizing var in loop for cleaner code
foreach (var round in rounds) {
    // Do something with each round
}

Tim konkluduje, zauważając, że choć var może zmniejszyć rozwlekłość, kluczowe jest upewnienie się, że nazwy zmiennych są jasne i opisowe, aby zachować czytelność i uniknąć zamieszania.

Równoważąc użycie var z jawnymi typami, programiści mogą pisać klarowny, łatwy do utrzymania i wydajny kod, korzystając ze ster w obu podejściach stosownie do kontekstu.

Var jako anonimowy obiekt

Tim omawia użycie var w sytuacjach, gdzie typ nie jest jawnie znany lub podczas pracy z anonimowymi typami. Demonstruje to, tworząc w locie obiekt anonimowy, który nie ma wcześniej zdefiniowanego typu. Oto kod, którego używa:

// Creating an anonymous object with var
var myItem = new { FirstName = "Tim", Email = "test@test.com" };

// Creating an anonymous object with var
var myItem = new { FirstName = "Tim", Email = "test@test.com" };

Tim, o 25:30, wyjaśnia, że skoro ten obiekt jest anonimowy i nie ma konkretnej nazwy typu, jedynym sposobem deklaracji zmiennych dla niego jest użycie var. To podejście pozwala na tworzenie i używanie obiektów bez potrzeby definiowania formalnej klasy.

Aby zilustrować, jak to działa w praktyce, Tim pisze (25:52):

// Outputting properties of an anonymous object
Console.WriteLine($"Hello {myItem.FirstName}: your email is {myItem.Email}");

// Outputting properties of an anonymous object
Console.WriteLine($"Hello {myItem.FirstName}: your email is {myItem.Email}");

Kiedy uruchamia kod o 26:25, wyjściem jest:

To pokazuje, że var może obsługiwać właściwości anonimowego obiektu, a Visual Studio dostarcza wsparcie dla IntelliSense dla tych właściwości, pomimo że obiekt jest anonimowy.

Tim, o 26:54, wyjaśnia, że preferuje używanie jawnych typów dla prostych i powszechnych typów jak string, liczby całkowite i instancje klas, ponieważ sprawia to, że kod jest bardziej przejrzysty. Jednak używa var w przypadkach, gdy typ jest albo długi, skomplikówany, albo nie jest jawnie znany, na przykład z anonimowymi typami lub skomplikówanymi deklaracjami typów.

Wnioski

I oto masz—jasne zrozumieniuiuiuiuie zmiennych i typów danych w C#, wraz ze strategicznym wykorzystaniem słów kluczowych var i dynamic. Podążając za zrównoważonym podejściem Tima Coreya, możesz zapewnić bezpieczeństwo typów i przejrzystość w swoim kodzie z var słowem kluczowym, jednocześnie korzystając z elastyczności dynamic słowa kluczowego w specyficznych scenariuszach, takich jak interakcja z zewnętrznymi systemami.

Aby uzyskać bardziej szczegółowe informacje, koniecznie obejrzyj wideo Tima Coreya na temat "Dynamic vs Var in C#" i sprawdź jego kanał YouTube po dalsze tematy związane z nauką C#.