Wann sollte man sich für statische Klassen entscheiden?

Question

Immer, wenn ich eine Lösung für etwas kodiere, tendiere ich dazu, entweder viele statische Klassen oder gar keine zu verwenden. Zum Beispiel musste ich in einem kürzlichen Projekt eine Klasse mit einigen string/bool/datetime Daten durch eine Anzahl von Ringen senden und das einzige, was nicht statisch war, war diese Daten haltende Klasse. Alles andere (3 ziemlich heftige Klassen mit unterschiedlichen Verarbeitungsaufgaben) waren statisch.

Ich denke, was ich hier frage ist eine Eingabe auf wann (und warum) sollte ich vermeiden, statische Klassen für diese Fälle "Prozess X, Ausgabe Y". Ist es in Ordnung, sie immer so lange zu benutzen, wie sie funktionieren oder schieße ich mich selbst in den Fuß bezüglich Skalierbarkeit, Plugin-Unterstützung usw.?

Ich hoffe, das ist eine gute Frage, die Sie hier stellen können. Ich frage nicht nach einem Argument, ob statische Klassen "besser" sind oder nicht, sondern nur, wann ich sie vermeiden sollte.

Answer 1

Immer noch die zwei Fragen bleiben ein bisschen gleich. Mein Hauptanliegen bei statischen Klassen ist Vererbung und Zugänglichkeit.

Bei Verwendung einer statischen Klasse (im schlimmsten Fall öffentlich) kann jeder auf Ihre Prozesse und Funktionen zugreifen. Welches ist die meiste Zeit nicht was du willst. Es ist zu leicht für ein Objekt, zu Ihren Funktionen zu gelangen und einige Modifikationen vorzunehmen. Daher ist die Abhängigkeitsinjektion angenehm zu verwenden. (Übergeben Sie das Objekt, das Sie ändern möchten, in den Parametern, in diesem Fall process-object).

Um zu verhindern, dass andere Ihre process-object manipulieren, warum nicht versuchen, eine Art Singleton-Muster (oder sogar ein Ex-Singleton-Muster) zu verwenden, also gibt es tatsächlich ein reales Objekt, mit dem man sprechen kann? Sie können das Objekt in die Parameter Ihrer Funktionen übergeben, wenn etwas geändert werden soll. Und dann können Sie nur einen Manager haben, der Ihre process-object hält. Andere sollten nicht zum Objekt kommen.

Statische Klassen sind auch schwer zu erben. Override statische Methoden scheint ein bisschen seltsam. Wenn Sie also sicher sind, dass der Prozess nicht der einzige Prozess sein wird und einige spezifischere Prozesse von Ihnen erstellt werden, sollte auch eine statische Klasse vermieden werden.

Answer 2

Statische Klassen werden normalerweise für kleine Datencontainer und allgemeine Methoden verwendet. Es sollte keine großen Daten enthalten, solange sie nicht benötigt werden. Diese Klassen sind nicht erweiterbar.

Answer 3

Der meiste Code i schreiben:

• Verwendet Dependency Injection/IoC
• und muss mockable/prüfbar

Also ich Objekte nur für fast alles verwenden.

I Statik haben noch für Dinge verwenden wie:

• Erweiterungsmethoden
• Konstanten
• Helper/Utility Methoden (pre-Erweiterungsmethoden)
• Operator Methoden

Answer 4

Ich würde Ihnen empfehlen, eine Methode als statisch zu haben, wenn sie nur eine Methode hat.In diesem Fall macht das Erstellen einer Instanz der Klasse keinen Sinn.

Sie können statische Eigenschaften haben, wenn Sie möchten, dass ein Feld ungefähr wie global variable funktioniert. Dies ist ein Entwurfsmuster, das zu Singleton pattern

passt Ich verwende statische Eigenschaften für den Tracking-Status, der von der gesamten Anwendung verbraucht werden muss.

für Ruhe alles zu meiner Arbeit Objekten im Zusammenhang ist die Art und Weise (mit geringfügigen Ausnahmen natürlich) zu gehen

Answer 5

extensiven Einsatz von Statik zu machen ist wie Ihre Anwendung in Beton Puting. Sie sollten vermieden werden, außer für sehr spezielle Situationen wie Hilfs-/Hilfsmethoden, die sehr allgemein sind. Eine schöne Liste wurde in einer früheren Antwort von Djeeg veröffentlicht.

Answer 6

Das Hauptproblem bei der Verwendung von statischen Klassen, wie Sie beschreiben, ist, dass die Abhängigkeiten fest verdrahtet sind. Wenn Klasse A Features aus Klasse B verwenden muss, muss explizit darüber informiert werden, was zu einer engen Kopplung führt.

Obwohl dies nicht immer ein Problem ist, wird es bei zunehmendem Code möglicherweise schwieriger, das Verhalten des Programms an neue Anforderungen anzupassen. Zum Beispiel, wenn Sie das Verhalten des Programms konfigurierbar machen wollen, wird es schwierig sein, denn das erfordert explizite Wenn/Schalter im Code. Andernfalls könnten Sie eine Klasse einfach von einer Schnittstelle abhängig machen und Implementierungen vertauschen.

Kurz gesagt, Sie verhindern, dass Sie bekannte Designmuster verwenden, die als gute Lösungen zur Lösung von Problemen bekannt sind, denen Sie wahrscheinlich begegnen werden.

Answer 7

Ich versuche normalerweise zu vermeiden, statische Methoden in Klassen zu verwenden. Wenn ich global auf einige Daten zugreifen möchte, würde ich zumindest eine Klasse in einen Singleton einbinden. Bei größeren Projekten würde ich empfehlen, einen Inversion-of-Control-Container zu verwenden, um Ihre "globalen" Instanzen auf Singleton-Art zu instanziieren und zu injizieren.