Sind statische C#-Variablen und -Methoden böse? Derek Comartin erklärt es (Video Breakdown)

Was macht eine statische Methode problematisch?

Zu Beginn des Videos geht Derek auf eine statische Methode namens Is18YearsOrOlder ein. Diese Methode nimmt ein DateTime birthDate und prüft, ob eine Person mindestens 18 Jahre alt ist. Sie verwendet DateTime.UtcNow, um das aktuelle Datum zu vergleichen. Einfach genug, oder?

Aber wie Derek betont, ist diese Methode nicht deterministisch. Bei 0:50 hebt er hervor, dass die Verwendung von DateTime.UtcNow bedeutet, dass die Methode unterschiedliche Ergebnisse liefert, je nachdem, wann Sie sie ausführen. Das ist ein großes Problem bei Unit-Tests und führt zu unerwartetem Verhalten im Code.

In diesem Fall sieht die Methode zwar wie eine reine Funktion aus, ist es aber nicht. Derek erklärt, dass eine reine Methode jedes Mal, wenn sie mit denselben Parametern aufgerufen wird, denselben Wert zurückgeben muss. Aber hier ändert sich das aktuelle Datum ständig, also ändert sich auch der Rückgabewert.

Dies veranschaulicht, wie eine öffentliche statische Methode, die zwar praktisch ist, zu Seiteneffekten führen kann, wenn sie von Echtzeitdaten oder dem Zustand der Anwendungsdomäne abhängt.

Statische Methoden testbar und vorhersagbar machen

Dereks nächster Punkt ist entscheidend: Wir können den Nicht-Determinismus beheben, indem wir die Abhängigkeit von DateTime.UtcNow entfernen. Stattdessen zeigt Derek, wie man einen Zeitanbieter mithilfe einer statischen Klasse oder einer Schnittstellenimplementierung einbindet. Dadurch wird die Funktion deterministisch - Sie erhalten jedes Mal die gleiche Ausgabe, wenn Sie die gleiche Eingabe übergeben.

In seiner PlaceOrder-Klasse führt er einen gefälschten Datumsanbieter ein, damit er testen kann, ob Bestellungen, die freitags bearbeitet werden, einen Rabatt von 50 % erhalten. Dadurch wird eine an die Systemzeit gebundene Hardcodelogik vermieden, was die Methode zuverlässiger und testbarer macht.

Durch die Isolierung des Verhaltens und die Vermeidung von Verweisen auf statische Methoden direkt innerhalb der Geschäftslogik zeigt Derek, wie man sauberen Code erhält und gleichzeitig die Testbarkeit beibehält.

Dichte Kopplung und statische Methoden

Derek warnt an dieser Stelle, dass der Rückgriff auf statische Methoden oft zu einer engen Kopplung führt. Wenn Sie DateTime.UtcNow direkt verwenden, sind Sie an diese Implementierung gebunden - Sie können sie nicht außer Kraft setzen oder nachahmen.

Dies ist ein Problem, weil statische Elemente wie diese in Ihrer Anwendung global sind. Wenn Ihre Codebasis in hohem Maße statische Felder oder statische Eigenschaften verwendet, wird es schwieriger, das Verhalten zu ändern oder Abhängigkeiten einzufügen, wodurch wichtige Grundsätze der objektorientierten Programmierung verletzt werden.

Sie verlieren auch an Flexibilität, da Sie dieses statische Feld nicht durch eine andere Implementierung ersetzen können, wie es bei einer Instanzvariablen oder einem injizierten Dienst möglich wäre.

Das Problem des globalen Zustands mit statischen Variablen

Jetzt wendet sich Derek den statischen Variablen zu, und hier wird die Unterhaltung ernst.

Er präsentiert ein Beispiel mit einem statischen Cache in einer Global-Klasse. Er erklärt, dass das größte Problem bei statischen Variablen der unbekannte Zustand ist. Zur Laufzeit können Sie nicht sicher sein, ob Ihr statisches Feld initialisiert wurde. Diese Unvorhersehbarkeit ist besonders riskant, wenn es sich um einen veränderbaren statischen int- oder String-Namen handelt.

Dieses Szenario wird noch schlimmer, wenn die Entwickler davon ausgehen, dass es nur eine Kopie dieser Variable gibt, die von allen Threads gemeinsam genutzt wird - und dabei vergessen, die Thread-Sicherheit zu berücksichtigen.

Thread-Sicherheit und statische Felder in Multithreading-Code

Derek bringt ein weiteres Problem zur Sprache: die Verwendung statischer Variablen in Multithreading-Umgebungen. Er gibt ein Beispiel für eine statische List, die gleichzeitig mit Parallel.For. Der Code stürzt ab, weil das statische Feld nicht thread-sicher ist.

Um dieses Problem zu lösen, wechselt er zu ConcurrentBag, einer in .NET verfügbaren thread-sicheren Sammlung. Dies ermöglicht einen sicheren Zugriff auf die statischen Daten über mehrere Threads hinweg.

Sein Standpunkt ist klar: Wenn Sie statische Variablen über Threads hinweg verwenden, stellen Sie sicher, dass sie thread-sicher sind. Andernfalls kann sich Ihr Programm unvorhersehbar verhalten oder sogar abstürzen.

Sichere Verwendung von statischen Methoden

Anschließend stellt Derek eine sichere und effektive Verwendung einer statischen Methode vor: die einfache Dienstprogrammmethode MilesToKilometers. Es nimmt einen int-Mile und gibt nach der Konvertierung einen double-Wert zurück. Diese Methode ist deterministisch - für den gleichen int-Wert erhalten Sie immer das gleiche Ergebnis.

Diese Art von Methode verlässt sich nicht auf nicht-statische Felder, verändert keine gemeinsamen Daten und beinhaltet keinen unbekannten Zustand. Es ist ein großartiges Beispiel dafür, wie man das statische Schlüsselwort in C# richtig verwendet.

Verständnis von Static im .NET-Kontext

In C# kann das Schlüsselwort static auf Klassen, Felder, Methoden, Konstruktoren und Eigenschaften angewendet werden. Derek berührt indirekt das Konzept von:

• Statische Klasse: Eine Klasse, die nicht instanziiert werden kann und nur statische Mitglieder enthalten kann.

• Statische Felder: Mit dem Schlüsselwort static deklariert - pro Anwendungsdomäne existiert nur eine Kopie.

• Statischer Konstruktor: Wird nur einmal ausgeführt, wenn auf die Klasse zum ersten Mal zugegriffen wird.

• Static void Main: Der Einstiegspunkt der meisten C#-Anwendungen, der zeigt, wie wichtig statische Methoden sein können.

• Statische int, statische string: Beispiele für statische Felder, die Daten speichern, die allen Instanzen der Klasse gemeinsam sind, oder die sogar überhaupt keine Instanz benötigen.

Im Gegensatz zu Instanzkonstruktoren, die jedes Mal ausgeführt werden, wenn Sie ein Objekt erstellen, initialisiert der statische Konstruktor die Ressourcen auf Klassenebene nur einmal.

Diese Unterscheidung hilft Entwicklern bei der Entscheidung, wann eine Instanzvariable und wann eine statische Variable zu verwenden ist oder wann Property-Accessors zur Kapselung von gemeinsam genutzten Member-Variablen eingesetzt werden sollten.

Abschließende Schlussfolgerungen von Derek

Derek fasst die Hauptgründe zusammen, warum Entwickler vor statischen Mitgliedern zurückschrecken:

• Enge Kopplung - Sie sind an das Verhalten dieser statischen Methode oder dieses statischen Feldes gebunden.

• Nicht-deterministisches Verhalten - schwer zu testen, leicht zu brechen.

• Global mutable state - Sie wissen nicht, was der Wert ist oder wer ihn geändert hat.

• Gleichzeitigkeitsprobleme - unsicherer Zugriff auf gemeinsame Daten in Multithreading-Code.

Doch, wie Derek sagt, Statik ist nicht böse. Es ist mächtig, wenn es richtig verwendet wird - vor allem in Hilfsfunktionen, gemeinsam genutzten Konstanten oder wirklich globalen Einstellungen. Sie müssen nur den Zustand sorgfältig verwalten und vermeiden, sich auf veränderliches oder systemspezifisches Verhalten zu verlassen.

Abschluss

Statische Variablen und Methoden sind in C# ein zweischneidiges Schwert. Wie Derek Comartin deutlich erklärt, sind sie nicht von Natur aus schlecht - aber sie erfordern eine durchdachte Nutzung. Verwenden Sie statische Felder und statische Klassen, wenn Sie gemeinsame Daten oder Funktionen benötigen, die nicht vom Objektstatus abhängen. Vermeiden Sie jedoch, sie für Dinge zu verwenden, die von der Zeit oder dem Systemzustand abhängen oder Flexibilität erfordern.

Bevor Sie also ein Objekt erstellen oder auf ein statisches Feld zugreifen, sollten Sie über Umfang, Testbarkeit und Thread-Sicherheit nachdenken und überlegen, ob der Code eine Kopie oder mehrere Instanzen benötigt.

Sehen Sie sich das vollständige Video von Derek Martin auf seinem CodeOpinion YouTube Kanal an. Sie erhalten weitere Einblicke in eine saubere Architektur, Softwaredesign und reale C#-Anwendungen.