AS3: Statische Klasse vs. Singleton

Ich kenne SO Kumpels sind nicht die fans von "versus" Fragen, aber... auch umformulieren die Pünktchen etwas, das gegen Teil ist immer noch da, also, warum verstecken Sie es.

Grundsätzlich, ich würde gerne wissen, Wann und warum sollte ich ein singleton oder eine statische Klasse, was die anbieten können ein singleton, dass eine statische Klasse nicht, und Umgekehrt.

Für eine lange Zeit, die ich verwendet beide, und ich kann nicht sehen, ein Grund, warum ich sollte nicht verwenden Sie einen über den anderen.

Dank.

  • können Sie erläutern, auf "statische Klasse" Konstruktion, weil "public static class" ist (noch) nicht unterstützt auf AS3 soweit ich weiß..
  • Sicher, ich meinte, dass eine Klasse mit Methode und Variablen statisch.
InformationsquelleAutor Artemix | 2012-12-08
  1. 8

    Beide sind im Grunde Globale Variablen mit Einschränkungen. Statische Klassen, Vererbung, und Singletons sind hässlich und fügen overhead mit einem Grundstück Suche. Beide machen automatisierte Tests schwierig.

    AS3 unterstützt Globale Variablen, also warum nicht diese verwenden?

    Statisch:

    package com.example
{
    public class Config
    {
        public static var VERSION:uint = 1;
    }
}

    Singletons:

    package com.example
{
    public class Config
    {
        public static var instance:Config = new Config();

        public var version:uint = 1;

        public function Config()
        {
            //Boiler plate preventing multiple instances
        }
    }
}

    Globale variable:

    package com.example
{
    public var config:Config = new Config();
}
class Config
{
    public var version:uint = 1;
}

    Nun, lassen Sie s sagen, obwohl du nur eine einzige Instanz der Klasse in Ihrer Produktion, app, müssen Sie mehrere Instanzen zum schreiben von tests. Sie können machen Sie eine öffentliche Klasse Config, und verwenden Sie com.example.config = new Config() zurücksetzen. Alle Orte, die Referenz Ihrer globalen Variablen werden jetzt mit der neuen Instanz, und Sie können sogar ausgefallene Dinge wie inheritence.

    Beispiel:

    if(inDebugMode)
{
    com.example.config = new DebugConfig();
}
{
    com.example.config = new Config();
}
    • Globale Variablen sind der ultimative side-Effekt, fehleranfällig und schwer zu Debuggen. Sie stellen Ihren code, starr und zerbrechlich, da viele der Klassen hängt von der Variablen vorhanden sein, am gleichen Ort und zu allen Zeiten. Nicht immer verwenden! Erwägen Sie stattdessen, die dependency injection (z.B. via swiftsuspenders.org ), die wil können Sie auch schaffen "Singletons", die es ermöglichen, für die erbschaft-und halten Ihre Klassen, schön entkoppelt.
    • swiftsuspenders.org ist sehr cool ! 🙂
    • Ich bin damit einverstanden, dass der Globale Zustand ist schlecht im Allgemeinen, aber ich denke, dass Globale Variablen sind besser als dependency injection für Dinge wie Logger-oder Dienstprogramme.
    • Globale Variablen sind nie besser als nichts. Setzen Sie Ihre logger in einer globalen mag einfacher und weniger code zu schreiben, schafft es aber auch eine starre Abhängigkeit, in deinem gesamten code-Basis, nicht weniger. Verwenden Sie ein ILogger-Schnittstelle, injizieren die Umsetzung - Sie können dann tauschen Sie Ihre logger jederzeit durch änderung Ihrer Konfiguration, und ohne neu kompilieren zu müssen alle Ihre Bibliotheken.
    • Sie können tun, dass mit einer globalen Variablen, wie der Letzte Teil meiner Antwort zeigt. Die Injektion ILogger in jeder Klasse ist nicht sehr elegant oder lesbar.
    • Nein, Sie können nicht. Mit dem weltweiten Ergebnis wird in allen Klassen nicht nur abhängig vom binäre für Logger, aber auch auf die konkrete Adressraum, wo der logger-Instanz gespeichert ist. Angenommen, Sie haben einen Kunden, der lieber ein etwas anderes setup, aus welchem Grund auch immer - jetzt haben Sie zu gehen, und ändern Sie alle Ihre Klassen überall. Die Injektion der ILogger scheint vielleicht nicht elegant, aber wenn Sie jemals etwas zu ändern, werden Sie bemerken, was Eleganz wirklich bedeutet: Halten Sie Ihre Klassen schön entkoppelt und gekapselt. Die Lesbarkeit Teils lehne ich ab: Das ist eine zusätzliche Zeile code pro Klasse.
    • Ich meine, im ernst, wie ist [Inject] public var log:ILogger; nicht lesbar?;

    InformationsquelleAutor Sean Fujiwara
Schreibe einen Kommentar