Frage

Sagen, dass ich eine Klasse, die eine einzelne Funktion auszuführen ist gemeint. Nach dem Ausführen der Funktion, kann es zerstört werden. Gibt es einen Grund einen dieser Ansätze zu bevorzugen?

// Initialize arguments in constructor
MyClass myObject = new MyClass(arg1, arg2, arg3);
myObject.myMethod();

// Pass arguments to method
MyClass myObject = new MyClass();
myObject.myMethod(arg1, arg2, arg3);

// Pass arguments to static method
MyClass.myMethod(arg1, arg2, arg3);

ich wäre absichtlich vage über die Details, um zu versuchen, Richtlinien für verschiedene Situationen. Aber ich habe wirklich nicht in haben Geist einfache Bibliotheksfunktionen wie Math.random (). Ich bin mehr der Klassen zu denken, dass einige spezifische, komplexe Aufgabe durchführen, aber nur eine (öffentliche) Methode erfordert, es zu tun.

War es hilfreich?

Lösung

Ich benutzen Utility-Klassen zu lieben mit statischen Methoden gefüllt. Sie machten eine große Konsolidierung der Hilfsmethoden, die sonst lägen um Redundanz und Wartung Hölle verursacht. Sie sind sehr einfach zu bedienen, keine Instanziierung, keine Entsorgung, nur fire'n'forget. Ich denke, dies ist mein erster Versuch war unwissentlich eine serviceorientierte Architektur zu schaffen - viele staatenlos Dienste, die nur sonst ihren Job und nichts tat. Als ein System, jedoch wächst, Drachen kommen.

Polymorphismus
Sagen wir die Methode UtilityClass.SomeMethod haben, die glücklich entlang summt. Plötzlich müssen wir leicht die Funktionalität ändern. Der größte Teil der Funktionalität ist die gleiche, aber wir haben trotzdem ein paar Teile zu ändern. Wäre es nicht eine statische Methode gewesen, könnten wir eine derivate Klasse machen und die Verfahren Inhalte nach Bedarf ändern. Da es sich um eine statische Methode ist, können wir nicht. Klar, wenn wir müssen nur Funktionalität hinzufügen, entweder vor oder nach der alten Methode, können wir eine neue Klasse erstellen und die alten in der es nennen - aber das ist nur grob

.

Schnittstelle Leiden
Statische Methoden können nicht über Schnittstellen für logische Gründe definiert werden. Und da wir nicht statische Methoden außer Kraft setzen können, sind statische Klassen nutzlos, wenn wir sie übergeben müssen durch ihre Schnittstelle um. Dies macht uns derzeit keine statische Klassen als Teil einer Strategie-Muster verwenden. Wir könnten einige Probleme flicken von Passieren Delegierten statt Schnittstellen .

Testing
Dies geht im Grunde Hand in Hand mit den Schnittstellen Leiden oben erwähnt. Da unsere Fähigkeit Implementierungen von Vertauschen sehr begrenzt ist, werden wir auch Probleme ersetzen mit Testcode Produktionscode. Auch hier können wir sie einpacken, aber es wird uns benötigt nur große Teile unseres Code ändern Wrapper anstelle der tatsächlichen Objekte in der Lage sein zu akzeptieren.

Fosters Blobs
Als statische Methoden in der Regel als Hilfsmethoden und Utility-Methoden werden verschiedene Zwecke haben in der Regel verwendet werden, werden wir schnell mit einer großen Klasse am Ende mit nicht-kohärenter Funktionalität gefüllt - im Idealfall jede Klasse soll innerhalb des Systems einen einzigen Zweck hat. Ich würde viel lieber eine fünf mal die Klassen, solange ihre Zwecke gut definiert ist.

Parameter Kriechen
Um damit zu beginnen, dass wenig süß und unschuldig statische Methode könnte einen einzigen Parameter nehmen. Als Funktionalität wächst, sind ein paar neue Parameter hinzugefügt. Bald werden weitere Parameter hinzugefügt, die optional sind, so schaffen wir Überlastungen des Verfahrens (oder nur Standardwerte hinzufügen, in Sprachen, die sie unterstützen). Schon nach kurzer Zeit haben wir eine Methode, die 10 Parameter verwendet. Nur die ersten drei wirklich erforderlich sind, Parameter 4-7 sind optional. Aber wenn der Parameter 6 angegeben ist, werden 7-9 erforderlich auch gefüllt werden ... Hätten wir eine Klasse mit dem einzigen Zweck geschaffen zu tun, was diese statische Methode tat, konnten wir dieses Problem lösen, indem sie in den erforderlichen Parametern in der Aufnahme Konstruktor, und ermöglicht dem Benutzer, optional durch Werte Eigenschaften einzustellen oder Methoden mehrere voneinander abhängige Werte zur gleichen Zeit einzustellen. Auch wenn ein Verfahren zu dieser Menge an Komplexität zugenommen hat, ist es höchstwahrscheinlich muss in seiner eigenen Klasse sein sowieso.

Verbraucher Anspruchsvolle eine Instanz von Klassen ohne Grund
erstellen Eines der häufigsten Argumente, warum die Nachfrage der Verbraucher unserer Klasse zum Aufrufen dieses einzelne Methode eine Instanz schaffen, während für die Instanz danach keine Verwendung zu haben? eine Instanz einer Klasse zu schaffen, ist ein sehr, sehr billig Betrieb in den meisten Sprachen, so Geschwindigkeit ist kein Problem. Hinzufügen eine zusätzliche Codezeile für den Verbraucher ist ein niedrig Kosten für das Fundament einer viel besser verwaltbar Lösung in der Zukunft. Und schließlich, wenn Sie das Erstellen von Instanzen vermeiden wollen, erstellen Sie einfach eine Singleton WRApper Ihrer Klasse, die für die einfache Wiederverwendung erlaubt - obwohl dies die Voraussetzung ist, dass Ihre Klasse staatenlos ist. Wenn es nicht staatenlos ist, können Sie immer noch statische Wrapper-Methoden erstellen, die alles im Griff, während immer noch alle Vorteile auf lange Sicht zu geben. Schließlich könnte man auch eine Klasse machen, die die Instanziierung versteckt, als ob es ein Singleton war: MyWrapper.Instance ist eine Eigenschaft, die gerade neue MyClass zurückgibt ();

Nur Sith Angebote in Absoluten
Natürlich gibt es Ausnahmen von meiner Abneigung gegen statische Methoden. True Utility-Klassen, die keine Gefahr darstellen aufblasen sind ausgezeichnete Fälle für statische Methoden - System.Convert als Beispiel. Wenn Ihr Projekt eine einmalige ohne Anforderungen für die zukünftige Wartung ist, ist die Gesamtarchitektur wirklich nicht sehr wichtig - statische oder nicht statisch, nicht wirklich wichtig -. Entwicklungsgeschwindigkeit hat jedoch

Normen, Standards, Normen!
Instanzmethoden verwendet, funktioniert aber nicht verhindern, auch statische Methoden verwenden, und umgekehrt. Solange es Gründe für die Differenzierung ist und es ist standardisiert. Es gibt nichts Schlimmeres als die Suche über eine Business-Schicht mit unterschiedlichen Implementierungsmethoden ausbreitende.

Andere Tipps

Ich ziehe die statische Art und Weise. Da die Klasse kein Objekt repräsentiert ist es nicht sinnvoll, eine Instanz davon zu machen.

Klassen, die nur für ihre Methoden existieren sollten statisch bleiben.

Wenn es keinen Grund gibt, eine Instanz der Klasse, um die Funktion dann die statische Implementierung verwenden, um auszuführen, erstellt zu haben. Warum machen die Verbraucher dieser Klasse eine Instanz erstellen, wenn man nicht benötigt wird.

Wenn Sie auf die Schaltfläche Zustand nicht speichern des Objekts, dann gibt es keine Notwendigkeit, es in erster Linie zu instanziieren. Ich würde gehen mit der einzigen statischen Methode, die Sie Parameter übergeben zu.

Ich würde auch warnen vor einer riesigen Utils-Klasse, die Dutzende von unabhängigen statischen Methoden hat. Dies kann in Eile desorganisiert und unhandlich bekommen. Es ist besser, viele Klassen zu haben, die jeweils mit wenigen, verwandten Methoden.

würde ich sagen, die statische Methode Format die bessere Option sei. Und ich würde die Klasse statische als auch machen, so würde man sich keine Sorgen machen über versehentlich eine Instanz der Klasse zu schaffen.

Ich weiß wirklich nicht, wie die Situation hier ist, aber ich würde es betrachten als ein Verfahren in einer der Klassen setzen, die arg1, arg2 oder arg3 gehört - Wenn Sie semantisch können sagen, dass einer dieser Klassen besitzen, das Verfahren würde.

Ich würde vorschlagen, dass sein schwer zu beantworten auf der Grundlage der bereitgestellten Informationen.

Mein Bauch ist, dass, wenn Sie nur eine Methode haben werden, und dass Sie gehen, um die Klasse sofort weg zu werfen, es dann eine statische Klasse machen, die alle Parameter übernehmen.

Natürlich ist es schwer, genau zu sagen, warum Sie eine einzelne Klasse nur für diese eine Methode erstellen müssen. Ist es die typische „Utilities-Klasse“ Situation, da die meisten davon aus? Oder Sie irgendeine Art von Regelklasse der Umsetzung, von denen es vielleicht mehr in der Zukunft sein.

Zum Beispiel hat die Klasse steckbar sein. Dann würden Sie eine Schnittstelle für Ihre ein Verfahren zu schaffen, und dann würden Sie alle Parameter in die Schnittstelle übergeben haben wollen, anstatt in den Konstruktor, aber man würde es statisch sein nicht wollen.

Kann Ihre Klasse gemacht statisch sein?

Wenn ja, dann würde ich es mache eine ‚Dienstprogramme‘ Klasse, dass ich meine all in one-Funktionsklassen setzen würde.

Wenn diese Methode staatenlos ist und Sie brauchen es nicht um passieren, dann macht es am meisten Sinn es als statisch zu definieren. Wenn Sie die Methode übergeben um tun müssen, könnten Sie mit einem

Für einfache Anwendungen und internal Helfer, würde ich eine statische Methode verwenden. Für Anwendungen mit Komponenten, bin liebend ich das Managed Extensibility Framework . Hier ist ein Auszug aus einem Dokument schreibe ich die Muster zu beschreiben, die Sie über meine APIs finden.

  • Dienstleistungen
    • Definiert durch eine I[ServiceName]Service Schnittstelle.
    • durch den Interface-Typ exportiert und importiert.
    • Die einzige Implementierung wird von der Host-Anwendung zur Verfügung gestellt und intern und / oder durch Erweiterungen verbraucht wird.
    • Die Methoden auf der Service-Schnittstelle Thread-sicher sind.

Als konstruiertes Beispiel:

public interface ISettingsService
{
    string ReadSetting(string name);

    void WriteSetting(string name, string value);
}

[Export]
public class ObjectRequiringSettings
{
    [Import]
    private ISettingsService SettingsService
    {
        get;
        set;
    }

    private void Foo()
    {
        if (SettingsService.ReadSetting("PerformFooAction") == bool.TrueString)
        {
            // whatever
        }
    }
}

würde ich einfach alles in den Konstruktor. etwa so:

new MyClass(arg1, arg2, arg3);// the constructor does everything.

oder

MyClass my_object(arg1, arg2, arg3);

Eine weitere wichtige Frage zu prüfen, ob das System mit einer Multithread-Umgebung ausgeführt werden würde, und ob wäre es Thread-sicher sein, eine statische Methode oder Variablen haben ...

Sie sollten ihr Augenmerk auf den Systemzustand zu zahlen.

könnten Sie in der Lage sein, die Situation alle zusammen zu vermeiden. Versuchen Sie so, Refactoring, dass Sie arg1.myMethod1(arg2, arg3) bekommen. Swap arg1 mit entweder arg2 oder arg3 wenn es mehr Sinn macht.

Wenn Sie keine Kontrolle über die Klasse von arg1, dann schmücken sie:

class Arg1Decorator
    private final T1 arg1;
    public Arg1Decorator(T1 arg1) {
        this.arg1 = arg1;
    }
    public T myMethod(T2 arg2, T3 arg3) {
        ...
    }
 }

 arg1d = new Arg1Decorator(arg1)
 arg1d.myMethod(arg2, arg3)

Die Begründung ist, dass in OOP, Daten und Methoden Verarbeitung, die Daten gehören zusammen. Und Sie alle Vorteile erhalten, dass Mark erwähnt.

Ich denke, wenn Eigenschaften Ihrer Klasse oder die Instanz der Klasse werden nicht in Konstrukteuren oder in Ihren Methoden verwendet werden, sind Methoden nicht wie ‚statische‘ Muster entworfen vorgeschlagen werden. statische Methode immer in ‚Hilfe‘ Art und Weise thinked werden sollte.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top