sind statische Klassen als schlechte Praxis betrachtet? Ich habe vor ein paar Tagen einen Artikel darüber gelesen (kann es nicht finden, tut mir leid), der im Grunde gesagt hat, dass statische Klassen (besonders diese "Hilfsklassen") typischerweise ein Zeichen für schlechten Code sind. Ist das richtig und wenn ja, aus welchen Gründen?Sollten Sie statische Klassen vermeiden?
Der Missbrauch von statischen Klassen kann als schlechte Praxis angesehen werden. Aber auch der Missbrauch jeder Sprache ist möglich.
Ich mache keinen Unterschied zwischen einer nicht statischen Klasse mit nur statischen Methoden und einer statischen Klasse. Sie sind im Grunde dasselbe, nur dass statische Klassen dem Compiler ermöglichen, die Absicht des Entwicklers durchzusetzen (keine Instantiierung dieser Klasse, bequeme Syntax für den Zugriff auf ihre Funktionalität, etc).
Wie Sie sagen, kann eine Vielzahl von "Helper" -Klassen Sie in Schwierigkeiten bringen (Design, Wartbarkeit, Lesbarkeit, Auffindbarkeit, andere Fähigkeiten ...). Kein Argument hier. Aber können Sie argumentieren, dass eine "Helper" -Klasse ist nie geeignet? Ich bezweifle das.
Tat verantwortlich Verwendung von statischen Klassen kann große Vorteile für Ihren Code hat:
Enumerable statische Klasse bietet eine Reihe von Erweiterungsmethoden der meisten von uns gekommen sind, zu lieben. Sie sind eine logische Gruppe von Funktionen/Geschäftslogik, die sich nicht auf eine Instanz eines bestimmten Typs beziehen.Also nein, im Allgemeinen ist es nicht schlecht trainieren. Benutze sie nur weise ...
Ein Unterschied (zu dem oben genannten) ist die Fähigkeit, sich im Laufe der Zeit besser an Änderungen anzupassen. Wenn Sie stattdessen Objekte verwenden, können Sie die gleiche Klasse mit zwei verschiedenen Einstellungen initialisieren und so eine größere Kapselung erreichen. – Teson
Nein, es ist nicht wirklich richtig.
Es gibt viele Funktionen, die nicht für eine Objektinstanz spezifisch sind und keinen Status erfordern. Betrachten Sie zum Beispiel 'Math' Funktionen.
Fast alle Sprachen haben so etwas wie:
y = Math.round(x);
So ist die 'runde' Funktion ist statisch. Sie könnten, wenn Sie verrückt waren, argumentieren für so etwas wie (C#):
class RoundFunction<T> : GeneralMathFunction<T>
{
public override T Operate (params object[] variables) {
..
}
}
Aber IMHO, würden Sie ein wenig seltsam sein, dies zu tun.
Sicherlich gibt es eine Zeit, in der zu viele statische Funktionen ein Zeichen dafür sind, dass etwas schief gelaufen ist, aber im Rahmen der Vernunft ist es nicht "schlecht".
Es gibt Anforderungen, wo Sie eine Dienstprogrammklasse haben, in der alle Methoden statisch sind. In diesem Fall, wenn Sie die Klasse statisch machen, zeigt dies deutlich Ihre Absicht an. Und zumindest in C# können Sie nicht statische Methoden in einer statischen Klasse haben.
Ich denke, das allgemeine Argument ist dagegen, den veränderbaren Zustand in statischen Klassen zu halten und sie im Grunde als globale Variablen zu verwenden. Mit statischen Hilfsmethoden in einer statischen Klasse ist nichts falsch.
Und warum globale Variablen schlecht sind, bin ich mir sicher, dass Sie zwischen hier und Google eine halbe Million Seiten und Blog-Einträge finden werden.
ja, das ist es was er * behauptet * aber es ist nicht was er tatsächlich zeigt. Statische Klassen (wie Math) sind NICHT äquivalent zu globalen Variablen, sie sind äquivalent zu globalen * Konstanten *. Selbst mit Parametern ist dies immer noch nicht logisch verschieden von Global-Konstanten-Arrays, -Listen usw. Ich kann mich nicht daran erinnern, dass sie ein großes Problem darstellen. – RBarryYoung
Ich habe meine Antwort bearbeitet, um anzuzeigen, dass ich veränderbaren Zustand in einer statischen Klasse meinte, nicht Konstanten. – Davy8
Hier sind einige Links zu einigen Google-Test-Blog-Posts darüber, warum statische Methoden die Testbarkeit Ihres Codes beeinträchtigen können, sowie warum statische Methoden (die den schlechten Teil von statischen Klassen darstellen) alle Arten von potentiell überraschender Kopplung einführen Interaktion zwischen Komponenten.
all diese Artikel werden vom selben Typen geschrieben. Es stellt sich heraus, dass er nur ein Ruby-Fanatiker ist. Seine ganze Argumentation ist in seinen eigenen Worten zusammengefasst: "Das grundlegende Problem bei statischen Methoden ist, dass sie prozedurale Codes sind. Ich habe keine Ahnung, wie man prozeduralen Code einheitlich testet." Beeindruckend. 50 Jahre Testmethodik gingen diesem Typen voraus und er weiß nichts davon. Das Einzige, was ich mir vorstellen kann, wäre peinlicher, als öffentlich zuzugeben, dass dies der Fall wäre, wenn der Rest von uns unsere Design- und Testmethoden auf die Meinungen von jemandem stützen würde, der seinen Weg durch das College geschlafen hat. – RBarryYoung
Er ist ein Idiot. Er behauptet, dass Sie, nachdem Sie eine statische Methode wie Abs() geschrieben haben, entscheiden werden, eine Menge zusätzlicher Geschäftslogik hinzuzufügen, die Sie nicht testen können. Der Punkt beim Testen einer logischen Einheit ist nicht, wie viel Arbeit darin ausgeführt wird, sondern dass sie die entsprechenden Ausgaben für alle möglichen Eingaben liefert. Wenn Sie mehr Code hinzufügen (statisch oder nicht), müssen Sie nur weitere Komponententests hinzufügen. –
Rbarry: Ich würde sagen, er ist mehr ein OO-Frömmler als ein Ruby-Frömmler, und sein Beitrag * wurde * als Schimpfwort bezeichnet :) –
ich für Methoden statische Utility-Klassen die ganze Zeit in meinem Code verwenden, die recht häufig genannt werden würde, aber ein Schmerz instanziieren. Ein Beispiel wäre eine einfache Protokollierung Klasse wie:
public static class Logging
{
public static UpdateAction(int id, object data)
{
SqlConnection connection = new SqlConnection("conn string from config file");
// more logic here...
}
}
, jetzt in keine Weise habe ich immer diese Klassen und Methoden speichern jede Art von globalem Zustand, da dies zu großen concurrancy Problemen führen können und im Allgemeinen nur schlecht Design.
Vermeiden Sie also keine statischen Klassen, vermeiden Sie einfach, dass diese statischen Klassen eine Art globalen Status beibehalten.
Wie testen Sie Ihre statischen Methoden? Wenn Sie sie umgestalten, wie stellen Sie sicher, dass Sie keine Regressionen eingeführt haben? – mcwyrm
Bedeutet es "Verwendung von statischen Klassen ist falsch" (in diesem Fall ist der Artikel falsch) oder "Statische Klassen sind oft in schlecht geschriebenen Code gefunden" (in diesem Fall heißt es nicht, dass statische Klassen an sich schlecht sind , aber sie werden manchmal falsch verwendet)
Statische Funktionen sind effizienter als nicht statische, da Sie keine Instanz eines Objekts erstellen müssen, um sie zu verwenden oder einen 'this' -Zeiger an Methodenaufrufe zu übergeben.
Die Verwendung von statischen Klassen, um globale Variablen zu halten, ist eine andere Sache - in diesem Fall ist die zugrunde liegende Regel nicht, dass "Statik ist schlecht", sondern "Globals sind schlecht".
Meinst du "statische Methode" statt? Die folgenden Beispiele, wie Math.round, sind Beispiele für statische Methoden, aber die Math-Klasse selbst ist nicht statisch. –
Nein, ich meinte statische Klassen. Ich habe silky's Beitrag kommentiert, um es zu klären. – Alex
Es wäre definitiv einfacher für uns, den Artikel zu widerlegen/zu akzeptieren, wenn wir genau wüssten, was es gesagt hat und ob es sich um einen bestimmten Kontext, eine bestimmte Sprache oder Designphilosophie handelt. –