Best Practice für Dienstprogramme Klasse?

Question

Wir haben derzeit eine Dienstprogramme-Klasse, die viele Zeichenfolgenformatierungen, Datumsanzeigen und ähnliche Funktionen verarbeitet, und es ist eine gemeinsame/statische Klasse.

Ist dies der "richtige" Weg, Dinge zu tun, oder sollten wir die Nutzungsklasse so und so instanziieren, wie wir sie brauchen?

Unser Hauptziel ist es, den Speicherbedarf zu reduzieren, aber die Leistung der Anwendung ist auch eine Überlegung.

PS. Wir verwenden .NET 2.0

Answer 1

Wenn überhaupt ein Zustand in der Klasse vorhanden ist, dann ist es am besten, Objekte daraus zu machen. Singletons sind ein Schmerz, in Bezug auf Objektabhängigkeiten und Thread-Sicherheit.

Wenn in der Klasse kein Status vorhanden ist, hat die Entscheidung, ob sie statisch ist oder nicht, keine nennenswerten Auswirkungen auf den Speicherbedarf.

Answer 2

Wenn Sie .NET verwenden, haben Sie sich mit Erweiterungsmethoden beschäftigt? Ich habe festgestellt, dass ich bei entsprechender Verwendung vielleicht gar keine Gebrauchsklasse brauche.

Answer 3

Ist dies in .NET? Wenn ja, kann es besser sein, Erweiterungsmethoden zur Verfügung zu stellen. Z.B. wenn Sie ein Dienstprogramm Methode, die einen String formatiert, ändern ihre Unterschrift unter

public static string SpecialFormat(string text) 

zu

public static string SpecialFormat(this string text) 

Auf diese Weise wird die SpecialFormat Methode weit mehr auffindbar sein, da es als eine Methode auf Zeichenfolge erscheint .

Answer 4

Wenn Ihre Sprache dies unterstützt, machen Sie diese Funktionen zu einem Paket/Namespace/Modul anstatt zu einer Klasse.

Wenn nicht, sind statische Methoden einer Klasse in Ordnung. Sie sollten die Klasse final/closed/nonvirtual/non-extendable markieren, wenn Ihre Sprache dies unterstützt.

Wenn Ihre Sprache dies unterstützt, können Sie die integrierten Klassen/Definitionen für die von diesen Funktionen akzeptierten Typen neu definieren, aber vermeiden Sie Namespace-Kollisionen. In diesem Fall sollten Sie auf den Stilführer oder De-facto-Standard Ihrer Sprache Ihrer Wahl verzichten, um den idiomatischen Ansatz zu wählen.

Answer 5

Statische Klassen sind gut für das, was Sie beschrieben haben - seien Sie nur vorsichtig, dass jeder gemeinsam genutzte Zustand (statische Membervariablen) auf threadsichere Weise gemeinsam genutzt wird.

Answer 6

Ist das die "richtige" Art, Dinge zu tun, oder sollten wir die Gebrauchsklasse so einrichten, wie und wann wir sie brauchen?

Von OOD Sicht ist es :-)

Für pure functions hängt Sie statische Methoden in Java/C# verwendet werden soll. In C# können Sie auch versuchen, Erweiterungsmethoden zu verwenden, wie andere beschreiben.

Für Utility-Methoden, die keine reinen Funktionen sind (zum Beispiel das Lesen einer Datei), sollten Sie eine Instanz erstellen, um die Testbarkeit zu verbessern (erlauben Sie zum Beispiel zu spotten).

Der Unterschied ist, dass die letzteren, obwohl sie keinen Zustand direkt behalten, sie mit einigen externen Komponenten kommunizieren, die ihren eigenen, möglicherweise sich ändernden Zustand haben. Dieser externe Zustand kann dazu führen, dass diese Dienstprogrammmethode im Laufe der Zeit (für die gleiche Eingabe) unterschiedliche Ergebnisse zurückgibt, was das Testen und Nachdenken erschwert. Es ist ein gutes Designprinzip, zwischen reinen Funktionen und solchen Hilfsmethoden zu unterscheiden, indem letztere als explizite Instanzmethoden angegeben werden.

In der Java-Praxis geht das "Mocking-Argument" jedoch in der Regel voraus, da statische Methoden nicht simuliert werden können.