Häufig sieht der Zugriff auf Singletons so aus:
|
1 |
MySingleton.getInstance().doStuff(); |
Effizienter finde ich aber
|
1 |
MySingleton.doStuff(); |
Siehe Bild. getInstance() ist dabei “internal static”
PS: “internal” ist vielleicht nicht nötig, aber “protected” ging irgendwann mal nicht, deswegen… sicher ist sicher^^
Warum so kompliziert?
Wenn es sich in der Tat um eine Singleton-Klasse handelt, braucht man keine Instanz. Alle Variablen und Funktionen werden einfach als static deklariert.
Will man allerdings unterklassen bilden, dann ist es in der Tat notwendig, eine Instanz zu von der statischen Methode auf die dynamische zu verweisen.
‘internal’ erlaubt uebrigens den zugriff von allen Klassen aus dem selben Paket heraus (was eigentlich unerwünscht ist), jedoch nicht von einer Unterklasse, die in einem anderen Paket definiert ist (was aber für ein override notwendig wäre). ‘protected’ ist daher das richtige Attribut.
internal: Weiß ich. Gewünscht hätte ich mir “private”, was aber mal nicht ging. Dem kommt “internal” näher als “protected”.
Wenn Du Wert auf “override” legst, hast Du Dir selber das Killer-Argument gegen static gegeben: Versuch mal, eine statische Funktion zu überschreiben 🙂 Das schreibst Du ja auch.
“Richtige” statische Klassen gibt es in AS ja eh nicht, sonst würdest Du auch dort die Einschränkung bemerken: Statische Klassen kann man nicht beerben. Wo man etwas ähnliches aber auch in AS bemerkt: Man kann keine statischen Funktionen aus einem Interface implementieren – “statische Klassen” (im Sinne von AS) können also keine Interfaces bedienen.
Funktional sind statische Klassen und Singletons oft ähnlich bis gleich. Aber von der Idee her sind sie es nicht. Ich würde immer der Idee folgen, das ist meist sauberer… Du würdest ja auch keine öffentlichen Klassenvariablen nutzen, nur weil in gettern/settern meistens eh nichts passiert.