Singleton Frage:

[Guest]

Hallo, angenommen ich habe diese SingletonKlasse:

public class Singleton {

    private static Singleton instance = null;
    private static Map<Object,Object>values;

    private Singleton () {}

    public static synchronized Singleton getInstance() {

        if (instance == null) {
            instance = new Singleton ();
        }
        return instance;
    }

   public static Map<Object,Object>getValues(){
      //mach irgendwas mit values und gib diese zurück
     return values;
   }
}

Nun möchte ich diese Klasse irgendwo aufrufen. Wo ist nun der Unterschied bei den beiden Aufrufen ?

Variante 1:

Singleton.getInstance().getValues();

Variante 2:

Singleton.getValues();

Und: würde etwas dagegen sprechen, die values Map public zu machen und dann von außerhalb einfach so aufzurufen:

Singleton.values;

Vielen Dank schonmal für nützliche Hinweise!
Mit besten Grüßen
Christian

 

[CK]

Public ist grundsätzcih schlecht. In ganz wenigen ausnahmefällen sollte man eine variable public machen (Thema Datenkapselung).

Singleton.getValues() da müsste die Methode static sein und somit muss kein Object der Klasse initiert werden.

Singleton.getInstance().getValues() greift auf ein über das einzige Object auf die Methode zu. In deinen Fall aber sinnlos weil die Methode static ist

Dein oberer Code solltest du also nochmal überdenken.
Zu empfehlen wer, wenn die Klasse schon Singleton ist, die Variablen auch Singleton zu machen oder du sparst die das Singleton und greifst direkt auf die Variablen mit getter und setter zu (static, aber besser nicht public Variablen).

Die erste Variante ist allerdings die eleganterer.

Gruß.

 

[maki]

Wozu ein Singleton? Und dann auch noch lazy-initialisiert...

 

[Wildcard]

1. Singeltons sind fast immer böse
2. Vergiss sowas am besten wieder:

        if (instance == null) {
            instance = new Singleton ();
        }

Straight Forward:

private static Singleton instance = new Singelton();

 

[CK]

Singleton ist in manchen Fällen ganz sinnvoll. Ein Beispiel wäre die Gui Entwicklung. Hier will man oft nur das z.B. ein Frame nur einmal vor kommt. Hierfür wäre Singleton gut.

 

[Wildcard]

Bis man merkt das man doch 2 Frames möchte und dann schreibt man das halbe Programm um. Man gewinnt durch das Singelton nichts und verliert seine Flexibilität.

 

[Guest]

Gut...Warum Singleton. So lautet halt die Aufgabenstellung...
Ok, Code ist abgeändert, aber wie wird die Map zum Singleton, so wie jetzt ist ?:

public class Singleton {

    private static Singleton instance = new Singleton();
    private static Map<Object,Object>values = new HashMap<Object,Object>();

    private Singleton () {}

    public static synchronized Singleton getInstance() {
        return instance;
    }

   public static Map<Object,Object>getValues(){
     return values;
   }
}

 

[Wildcard]

Mach das static weg. Nur getInstance und die Instance selbst sollen static sein.

 

[CK]

Singleton ist wenn schon die Klasse und nicht die Map.
Aber wenn ich dich richtig verstehe willst du nur eine Instanz von der Map mit einem einzigen Object.
Das würde bedeuten das du nur das static vor map (Variable und Methode) wegnehmen musst.

 

[CK]

Um zu wissen ob eine bestimmte Oberfläche nur einmal oder mehrfach existiern soll, plant man seine Programme ja auch.
Jede Technik hat ihre vor und Nachteile. Als grundsätzlich schlecht würde ich Singleton nicht abhaken.
Besonders wenn es um Speicherlast geht.

 

[Wildcard]

Speicherlast? Wenn du ein Objekt nur einmal anlegst, ist es genauso oft vorhanden wie bei einem Singelton. Der unterschied: Ein normales Objekt kann vom GC kassiert werden, ein Singelton setzt sich im Speicher fest, was ist also besser?

 

[Guest]

Danke für die schnelle Hilfe! Aber ich glaube ich bin jetzt verwirrt..Dies sei nun meine Klasse

public class Singleton {

    private static Singleton instance = new Singleton();
    private Map<Object,Object>values = new HashMap<Object,Object>();

    private Singleton () {}

    public static synchronized Singleton getInstance() {
        return instance;
    }

   public Map<Object,Object>getValues(){
     return values;
   }

}

Wie instanzier ich nun ein Objekt dieser Klasse , was ist korrekt ?

private static Singleton singleton = Singleton .getInstance();

oder

private Singleton singleton = Singleton .getInstance();

 

[Wildcard]

wie du willst, spielt keine Rolle.

 

[byte]

Das einzige Problem am Singleton ist, dass man dank statischer Zugriffsmethode von überall an das Objekt dran kommt. Das kann schnell chaotische Auswüchse annehmen, wenn man von zig Stellen im Code die Singletons verwendet. Ganz schlimm wirds, wenn dann noch Singletons auf andere Singletons zugreifen oder wenn man später das Projekt in mehrere Java-Projekte (oder Plugins) umstrukturieren möchte. Da handelt man sich sehr schnell sehr unschöne zyklische Abhängigkeiten ein.

Aus diesem Grund sollte man in den meisten Fällen auf Singletons verzichten. Nur weil nur eine Instanz einer Klasse denkbar sind, muss man nicht zwangsläufig ein Singleton draus machen. Ganz pragmatisch könnte man einfach nur eine Instanz davon erzeugen und in der Doku entsprechend darauf verweisen, dass nur eine Instanz der Klasse Sinn macht.

Ansonsten gibt es auch andere Möglichkeiten, Singletons ohne statische Zugriffsmethode zu implementieren:

public class BetterSingleton {
    private static boolean exists = false;
    
    public BetterSingleton() {
        if (BetterSingleton.exists) {
            throw new RuntimeException();
        }
        BetterSingleton.exists = true;
    }
}

 

[CK]

Ich sag ja kommt auf den Anwendungsfall an.
Haste zum Beispiel einen Listener gebaut der nix berauschendes macht aber an tausend verschiedenen Stellen im Programm benötigt wird, müsstest du die ganze Zeit die Referenz aufbewahren usw..
Also würden vermutlich vielen einfach jedesmal einen neuen Listener erstellen.
Und 100 mal nix berauschendes kann doch was speicherlastiges werden.
In dem Fall könnte man ein Singleton verwenden.

Was ich damit sagen will. Man kann jetzt wahrscheinlich viele Argumente für Singleton finden und genau soviele dagegen.
Einen gescheiten Fall zum einzatz gibt es immer.

Man muss für alles offen sein und öfter mal auch andere Möglicheiten in Betracht ziehen.

 

[byte]

Was ich damit sagen will. Man kann jetzt wahrscheinlich viele Argumente für Singleton finden und genau soviele dagegen.
Einen gescheiten Fall zum einzatz gibt es immer.

Ich gebe Dir ja insofern recht, dass der akademische Sinn und Zweck eines Singletons das Pattern durchaus rechtfertigt. Nicht ohne Grund findet man das Pattern im bekannten Buch der GOF. Aber die Praxis hat halt gezeigt, dass das Pattern häufig mißbraucht wird, um sich die Arbeit zu ersparen, Referenzen zu übergeben. Das macht das Singleton zum Antipattern.

Sicherlich kann man Speicher sparen, indem man nur 1 Objekt einer Klasse erzeugt statt viele. Aber das kann ich auch bewerkstelligen, ohne die bekannte Singleton-Antipattern Implementierung zu verwenden.

Eine alternative Implementierungsmöglichkeit des Singletons ohne statische Zugriffsmethode habe ich ja auf Seite 1 gepostet.

 

[tfa]

Ich sag ja kommt auf den Anwendungsfall an.
Haste zum Beispiel einen Listener gebaut der nix berauschendes macht aber an tausend verschiedenen Stellen im Programm benötigt wird, müsstest du die ganze Zeit die Referenz aufbewahren usw..
Also würden vermutlich vielen einfach jedesmal einen neuen Listener erstellen.
Und 100 mal nix berauschendes kann doch was speicherlastiges werden.
In dem Fall könnte man ein Singleton verwenden.

Nettes Beispiel für ein Anti-Pattern. Nennt man glaub ich "Außerirdische Spinne". Ein globales Objekt, das von der ganzen Welt benutzt wird. Wenn es verändert wird, hat das auf 1000 Stellen Auswirkungen.

Man muss für alles offen sein und öfter mal auch andere Möglicheiten in Betracht ziehen.

Für dieses Beispiel empfehle ich einen Event-Bus.

 

[Wildcard]

An denen Stellen an denen ein Singelton Sinn machen könnte und garantiert keinen Schaden anrichten kann (das sind äusserst wenige Stellen), bin ich zu folgendem Konstrukt umgeschwenkt.
Eine Klasse hält eine Instanz auf sich selbst und eine statische Zugriffsmethode für diese Instanz. Anderes als bei einem Singelton jedoch nicht getInstance, sondern getDefault.
Der Konstruktor ist im Gegensatz zu Singeltons nicht private, sondern public.
Damit hat man das, was die meisten mit einem Singelton bezwecken wollen (einfachen Objektzugriff) und gleichzeitig ein wenig den 'bad smell' entfernt.
Dennoch muss auch diese Variante mit Bedacht und sehr sparsam eingesetzt werden, weil globaler Zugriff nunmal das Gegenteil von Kapselung ist