Czy zmienne i metody statyczne C# są złe? Derek Comartin wyjaśnia (wideo breakdown)

Co sprawia, że metoda statyczna jest problematyczna?

Na początku wideo Derek wchodzi w metodę statyczną o nazwie Is18YearsOrOlder. Ta metoda pobiera DateTime birthDate i sprawdza, czy ktoś ma co najmniej 18 lat. Używa DateTime.UtcNow do porównania z aktualną datą. Proste, prawda?

Ale jak zauważa Derek, ta metoda jest niedeterministyczna. W 0:50 podkreśla, że używanie DateTime.UtcNow oznacza, że metoda zwróci różne wyniki w zależności od tego, kiedy zostanie uruchomiona. To poważny problem w testach jednostkowych i powoduje nieoczekiwane zachowanie w kodzie.

W tym przypadku, chociaż metoda wygląda jak czysta funkcja, to taką nie jest. Derek wyjaśnia, że czysta metoda musi zwracać tę samą wartość za każdym razem, gdy jest wywoływana z tymi samymi parametrami. Ale tutaj, aktualna data ciągle się zmienia, więc wartość zwracana również się zmienia.

To ilustruje, jak publiczna metoda statyczna, mimo że jest wygodna, może wprowadzać efekty uboczne, jeśli zależy od danych w czasie rzeczywistym lub stanu domeny aplikacji.

Uczynienie metod statycznych odpowiednimi do testowania i przewidywania

Następny punkt Dereka jest kluczowy: możemy naprawić niedeterministyczność, usuwając zależność od DateTime.UtcNow. Zamiast tego, Derek pokazuje, jak wstrzyknąć dostawcę czasu za pomocą klasy statycznej lub implementacji interfejsu. To czyni funkcję deterministyczną — za każdym razem, gdy podasz te same dane wejściowe, otrzymasz ten sam wynik.

W swojej klasie PlaceOrder wprowadza fałszywego dostawcę dat, aby móc przetestować, czy zamówienia przetwarzane w piątek dostają 50% zniżki. To unika zakodowanej logiki związanej z czasem systemu, czyniąc metodę bardziej niezawodną i testowalną.

Izolując zachowanie i unikając bezpośrednich odniesień do metod statycznych we wnętrzach logiki biznesowej, Derek pokazuje, jak zachować czystość kodu przy jednoczesnym utrzymaniu możliwości testowania.

Wąskie powiązanie i metody statyczne

W tym momencie Derek ostrzega, że poleganie na metodach statycznych często wprowadza wąskie powiązanie. Jeśli bezpośrednio używasz DateTime.UtcNow, jesteś związany z tą implementacją — nie możesz jej nadpisać ani udawać.

To jest problem, ponieważ członkowie statyczni tacy jak ten są globalni w całej aplikacji. Jeśli baza kodu intensywnie używa pól statycznych lub właściwości statycznych, staje się trudniej zmienić zachowanie lub wstrzyknąć zależności, łamiąc kluczowe zasady programowania obiektowego.

Tracisz również elastyczność, ponieważ nie możesz zastąpić tego statycznego pola inną implementacją, tak jak mógłbyś to zrobić z zmienną instancyjną lub wstrzykniętą usługą.

Problem globalnego stanu ze statycznymi zmiennymi

Teraz Derek kieruje swoją uwagę na zmienne statyczne, i tutaj rozmowa staje się poważna.

Przedstawia przykład używający statycznej pamięci podręcznej w klasie Global. Wyjaśnia, że największym problemem ze zmiennymi statycznymi jest nieznany stan. Podczas działania nie możesz być pewny, czy twoje pole statyczne zostało zainicjalizowane. Ta nieprzewidywalność jest szczególnie ryzykowna, gdy mamy do czynienia z mutującym statycznym int lub string name.

Ta sytuacja staje się jeszcze gorsza, gdy programiści zakładają, że istnieje tylko jedna kopia tej zmiennej współdzielona między wieloma wątkami — i zapominają uwzględnić bezpieczeństwo wątków.

Bezpieczeństwo wątków a pola statyczne w kodzie wielowątkowym

Derek podnosi kolejny problem: używanie zmiennych statycznych w środowiskach wielowątkowych. Podaje przykład statycznego List używanego równocześnie z Parallel.For. Kod się zawiesza, ponieważ pole statyczne nie jest bezpieczne dla wątków.

Aby rozwiązać ten problem, przechodzi na ConcurrentBag, bezpieczną dla wątków kolekcję dostępną w .NET. To umożliwia bezpieczny dostęp do danych statycznych w wielu wątkach.

Jego punkt jest jasny: jeśli używasz zmiennych statycznych w wielu wątkach, upewnij się, że są bezpieczne dla wątków. W przeciwnym razie twój program może działać nieprzewidywalnie lub nawet się zawiesić.

Bezpieczne użycie metod statycznych

Derek dzieli się następnie bezpiecznym i skutecznym użyciem metody statycznej: prostą metodą narzędziową MilesToKilometers. Pobiera int miles i zwraca wartość double po konwersji. Ta metoda jest deterministyczna — dla tej samej wartości int zawsze otrzymasz ten sam wynik.

Tego rodzaju metoda nie opiera się na polach niestatycznych, nie mutuje współdzielonych danych i nie dotyczy żadnego nieznanego stanu. To świetny przykład, jak właściwie używać słowa kluczowego static w C#.

Zrozumienie static w kontekście .NET

W C# słowo kluczowe static można zastosować do klas, pól, metod, konstruktorów i właściwości. Derek pośrednio dotyka koncepcji:

• Klasa statyczna: Klasa, której nie można zainstalować i może zawierać tylko członków statycznych.

• Pola statyczne: Deklarowane za pomocą słowa kluczowego static — istnieje tylko jedna kopia w domenie aplikacji.

• Konstruktor statyczny: Uruchamia się tylko raz, gdy klasa jest pierwszy raz dostępna.

• Static void Main: Punkt wejściowy większości aplikacji C#, demonstrujący, jak metody statyczne mogą być niezbędne.

• Static int, static string: Przykłady pól statycznych, które przechowują dane wspólne dla wszystkich instancji klasy, a faktycznie nie wymagają żadnej instancji.

W przeciwieństwie do konstruktorów instancyjnych, które uruchamiają się za każdym razem, gdy tworzysz obiekt, konstruktor statyczny tylko inicjalizuje zasoby na poziomie klasy raz.

To rozróżnienie pomaga programistom zdecydować, kiedy używać zmiennej instancyjnej kontra statycznej, lub kiedy używać akcesorów właściwości do kapsułkowania współdzielonych zmiennych członkowskich.

Ostateczne wnioski od Dereka

Derek podsumowuje główne powody, dla których programiści przestrzegają przed członkami statycznymi:

• Wąskie powiązanie — jesteś związany z zachowaniem tej metody statycznej lub pola.

• Niedeterministyczne zachowanie — trudne do przetestowania, łatwe do zepsucia.

• Globalny stan zmienny — nie wiesz, jaka jest wartość lub kto ją zmienił.

• Problemy z równoczesnością — niebezpieczny dostęp do danych współdzielonych w kodzie wielowątkowym.

Jednak, jak mówi Derek, static nie jest zły. Jest potężny, gdy jest używany poprawnie — zwłaszcza w funkcjach narzędziowych, współdzielonych stałych, lub naprawdę globalnych ustawień. Wystarczy tylko uważnie zarządzać stanem i unikać zależności od zmiennej lub specyficznego dla systemu zachowania.

Wnioski

Zmienne i metody statyczne są miećzem obosiecznym w C#. Jak wyjaśnia jasno Derek Comartin, nie są same w sobie złe — ale wymagają przemyślanej używalności. Używaj pól statycznych i klas statycznych, gdy potrzebujesz danych współdzielonych lub funkcjonalności, która nie zależy od stanu obiektu. Ale unikaj używania ich do rzeczy, które zależą od czasu, stanu systemu lub wymagają elastyczności.

Więc zanim stworzysz obiekt lub uzyskasz dostęp do pola statycznego, pomyśl o zakresie, możliwości testowania, bezpieczeństwie wątków i czy kod potrzebuje jednej kopii, czy wielu instancji.

Obejrzyj pełne wideo Dereka Martina na jego kanale CodeOpinion YouTube. Znajdziesz więcej wglądów na temat czystej architektury, projektowania oprogramowania i rzeczywistych zastosowań C#.