Frage zu Singleton

[EinGast]

Hallo zusammen!
Bei SWT bin ich auf ein problem gestoßen: wie realisiert man ein Singleton, wenn der Konstruktor einen Übergabeparameter hat?
Wenn ich jetzt eine eigene Klasse implementiere, von der es nur ein Exemplar geben wird, jedoch die Parameter für den Konstruktor unterschiedlich sein können...
wie macht man das üblicherweise?
Ich habs bisher so gemacht:

public class ABC extends XYZ{
	private static ABC instance = null;

	private Table(int a, int b, int c, int d) {
		super(a, b, c, d);
	}

	public static ABC getInstance(){
		return instance;
	}

	public static ABC getInstance(int a, int b, int c, int d){
		if (instance==null){
			instance = new ABC(a, b, c, d);
		}
		return instance;
	}
}

So wirklich zufriedenstellend ist das ganze aber nicht. Zuerst muss getInstance(a,b,c,d) aufgerufen werden und anschließend kann erst getInstance() aufgerufen werden. Sonst wird null zurückgegeben und es hagelt nur so Null-Pointer-Exceptions. Wenn jedoch bereits eine Instanz existiert und man ruft noch einmal getInstance(a,b,c,d) auf, so werden die Parameter ignoriert. Das halte ich auch für keine so tolle Lösung...

Wie wird das üblicher Weise realisiert?

 

[Bleiglanz]

So wirklich zufriedenstellend ist das ganze aber nicht. Zuerst muss getInstance(a,b,c,d) aufgerufen werden und anschließend kann erst getInstance() aufgerufen werden.

das geht so eben nicht, lass die getInstance() eine illegal State Ex werfen (sowas wie ein Singleton "mit Parametern" macht wenig sinn)

=> du musst nachhher immer checken, ob getInstance(a,b,c,d) schon aufgerufen wurde, da kommst du nicht drum herum

oder es gibt default werte

public static ABC getInstance(){
      if(null==instance) instance = ABC.getInstance(0,1,2,3);
      return instance;
   }

was soll das Table ? Poste richtigen Quelltext?

 

[foobar]

So wirklich zufriedenstellend ist das ganze aber nicht. Zuerst muss getInstance(a,b,c,d) aufgerufen werden und anschließend kann erst getInstance() aufgerufen werden.

Warum? getIstance(int, int, int ,int) liefert doch ein ABC-Objekt, dadurch ist die Methode getInstance() obsolet.

 

[EinGast]

So wirklich zufriedenstellend ist das ganze aber nicht. Zuerst muss getInstance(a,b,c,d) aufgerufen werden und anschließend kann erst getInstance() aufgerufen werden.

das geht so eben nicht, lass die getInstance() eine illegal State Ex werfen (sowas wie ein Singleton "mit Parametern" macht wenig sinn)

=> du musst nachhher immer checken, ob getInstance(a,b,c,d) schon aufgerufen wurde, da kommst du nicht drum herum

Hast du da was genaueres. Ein Stück BeispielCode oder ein Link, wo das ganze genauer beschrieben ist, wäre hilfreich...

was soll das Table ? Poste richtigen Quelltext?

Table ist eine meiner Klassen, bei denen ich das Problem habe. Die Superklasse ist auch eine eigene. Es wäre zu komplex hier alles zu posten, dann müsste ich etliche Klassen posten, die wild miteinander verstrickt sind. Bin grad dabei das ganze erstmal vernpnftig zu dokumentieren und ein bisschen besser zu strukturieren...

 

[helium]

Gibt es denn nur einste Stelle, von der aus Instanziert werden kann? oder gibt es möglicherweise Verschiedene Stelle, die die geforderten PArameter für die Instanzierung kennen?

Man muss ja nicht immer strikt an der üblichen Implementierung kleben bleiben. Vielleicht ist ja sowas viel geeigneter:

public class ABC extends XYZ{ 
   private static ABC instance = null; 

   private Table(int a, int b, int c, int d) { 
      super(a, b, c, d); 
   } 

   public static ABC getInstance() { 
      assert (isntance != null);
      return instance; 
   } 

   public static void instanciate (int a, int b, int c, int d) { 
      assert (instance == null);
      instance = new ABC(a, b, c, d); 
   } 
}

Die eine Stelle, die Weis, wie man instanziert ruft 'instanciate' mit den nötigen Argumenten auf, sonst wird einfach 'getInstance' verwendet.

 

[foobar]

Das ist das erste mal, daß ich assert in einem realen Programm sehe :shock:
Macht aber, meines Erachtens, trotzdem keinen Sinn.

 

[Bleiglanz]

Warum? getIstance(int, int, int ,int) liefert doch ein ABC-Objekt, dadurch ist die Methode getInstance() obsolet.

schönes Singleton, bei dem man immer alle vier Parameter mitgeben muss, ausserdem geht das ganze dann kaputt

getInstance(1,2,3,4) liefert eines

das nächste

getInstance(234,234,234,23) liefert das gleiche wie 1,2,3,4; da wären ja die Parameter EGAL

das ganze ist käse, ein Singleton macht eigentlich nur dann Sinn, wenn es einen parameterlos ist (sonst wärs ja eine Map oder ein pool von Objekten)

 

[EinGast]

Es gibt nur eine Instanz dieser Klasse. Mehr ist nicht notwendig und würde nur verwirren. Je nach dem von was die Instanz initialisiert , sind die Parameter unterschiedlich. Ich habe das Problem bei verschiedenen Klassen, so dass es nicht immer 4 Parameter (auch nicht alles int) sind. Meist tritt das bei von SWT-Widgets vererbten Klassen auf. Dort brauche ich auf jeden Fall einen Parameter (Widget parent) und nicht selten einen Parameter (int style). Je nach dem wo die Instanz erzeugt wird, sind die Parameter unterschiedlich.
Ich glaub ich weiß, wie ich's mache: Ich nehm meine aktuelle Klasse als Superklasse und lege ein paar weitere Klassen an, die von dieser erben und die Paramter fest verdrahtet sind. Dann kann ich diese als Singleton realisieren oder ich lass den ganzen Singleton-Quatsch...

ne andere Frage: Was macht dieses assert? Ich seh das hier zum ersten mal...

 

[virgie82]

ich poste mal an dieser stelle einen auszug aus einem javabuch:
du benutzt die singleton auch nicht richtig.

Wichtige Designmerkmale einer Singleton-Klasse sind:

Sie besitzt eine statische Membervariable ihres eigenen Typs, in dem die einzige Instanz gespeichert wird.
Sie besitzt eine statische Methode getInstance, mit der auf die Instanz zugegriffen werden kann.
Sie besitzt einen privaten parameterlosen Konstruktor, um zu verhindern, daß andere Klassen durch Anwendung des new-Operators eine Instanz erzeugen (er verhindert allerdings auch das Ableiten anderer Klassen).

001 public class Singleton
002 {
003   private static Singleton instance = null;
004 
005   public static Singleton getInstance()
006   {
007     if (instance == null) {
008       instance = new Singleton();
009     }
010     return instance;
011   }
012 
013   private Singleton()
014   {
015   }
016 }

hoffe ich bin jetzt niemandem mit meiner bücherbesitzenden klugscheißerei auf den schlips getreten ;-)

 

[EinGast]

so kenn ich Singleton ja auch.
dieses scheiß swt ist imho einfach beschissen designed. es gibt swt-widgets, die ich mir schon speziell angepasst habe. von denen solls aber nur genau 1 geben! also singleton. nur das geht ja nicht so wirklich...
in nem andren fall, stolper ich schon wieder über das Problem, dass ich beim Aufruf des Constructor das Parent übergeben muss. ich finds einfach nur bescheiden...

 

[helium]

Naja, ich bin halt eigentlich C++-Programmierer, und wir haben eine Hang dazu alles zu "asserten".

to assert bedeutet behaupten. Man stellt also eine Behauptung auf.
In

   public static ABC getInstance() { 
      assert (instance != null); 
      return instance; 
   }

Behaupte ich, das 'instance' nicht null ist. Generell behauptet man eifnach alles, was andernfalls ein logischer Fehler wäre.
Wenn man das halbwegs konsequent durchzieht findet man so verdammt schnell Logikfehler, oftmals an stellen, die man nie vermutet hätte.
Sie helfen auch dabei mutiger zu werden Code mal umzustellen.

Das Tolle an Assertions ist, das sie abschaltbar sind. Das heißt ich kann mein Projekt mi asserst vollstopfen bis zum Abwinken und nacher, wenn ich das Projekt veröffentliche habe ich absolut keinen Geschwindigkeitsverlust.


Vielleicht einfach mal nach "Design by Contract" suchen.

 

[EinGast]

Aber was ringt das?
Dann ist das Singleton fürn Ärmel

wenn es schon ne Instanz gibt und ich ruf getInstance(Parameter) auf, dann legt er mir ne neue an...
und wenn es noch keine gibt und ich ruf dann GetInstance() auf, krieg ich trotzdem null zurück...

oder blick ich das grad net?

tut mir leid, ich wurd ziemlich viel mit GUI-Design gequält und habe dabei eins gelernt: Die Dummheit der user ist unendlich. Wenn ich in 2 Jahren meine Klassen nehme, weiß ich auch nicht mehr was ich geschrieben hab und bin damit auch "user" meiner klassen. Und da sollte die schnittstelle schon wie erwartet arbeiten...

 

[EinGast]

ahja. ich hab mal ein bisschen gegoogelt
in http://www.kbs.uni-hannover.de/Lehre/SWTG/S12.pdf auf seite 3 der pdf ists beschrieben.
würde mir zwar prinzipiell helfen, mit der dummheit der user umzugehen, aber ich möcht nach möglichkeit von den beiden methoden weg.
vielleicht werd ichs wirklich so machen, dass ich in getInstance() auch auf null prüfe und den construktor mit standard-parametern aufrufe. dann kann ich das (glaub ich) so verwenden, wie ich will. die standardparameter würden das prog ja net zum absturzbringen, sondern in erster linie die gui versauen...

 

[Bleiglanz]

Du leidest wahrscheinlich an der weit verbreiteten Singletonitis.....

Symptome: Singleton Pattern halb verstanden und dann immer und überall verwenden.....

=> wenn dein "Einsatz" Parameter hat, dann taugt es nicht zum Singleton, so einfach ist das!


Überleg dir lieber mal, WANN getInstance(1,2,3,4) aufgerufen werden soll? beim Programmstart? oder hängt das von benutzereingaben ab?

WENN du das wirklich brauchst, dann mach halt sowas

class Key {
    public int a,b,c,d; // besser mit gettern (read only machen)
}

class Pool {
     // evtl. synchronized
     private final static Map vals = new HashMap(); 

     private static getInstance(int a, int b , int c , int d) {
         Key key = new Key(a,b,c,d);
         XXX val = map.get(key);
         if (null!=val) return val;
         val = new XXX(key);
         map.put(key,val);
         return val;
     }
}

 

[stev.glasow]

Bei der Klasse Key fehlen noch die equals(Object) und hashCode(), nicht dass das einfach unvollständig übernommen wird.

 

[EinGast]

jenachdem, welche Einstellung (z.B. CheckBox gesetzt oder nicht oder was auch immer), soll der Konstruktor unterschiedlich aufgerufen werden. dann muss ich halt ne normale getInstance machen und im konstruktor bzw. in der getInstance die Parameter abfragen. Wenn einmal ein Objekt erstellt wurde, darf/sollte es kein zweites davon geben. Wenn an es nicht mehr braucht kann man es disposen (muss man ja bei swt von hand machen) und kann ein neues Objekt mit anderen Parametern aufrufen, wobei es dann wieder nur 1 geben sollte/darf.

scheiß swt! wenns dort nen parameterlosen konstruktor gäb und sich die parameter anschließend mit setter-methoden setzen lassen würden, wär das alles kein prob. aber es muss ja immer das parent (kann sich bei einer Klasse ändern) und den Style (sollte sich auf jeden Fall individuell ändern lassen).
Es ist halt so, dass das schon ziemlich angepasste sachen sind, von denen es nur eine Instanz geben darf/sollte. nur die kann eben unterschiedlich aussehen.

mit der "Singletonitis" hast du nicht ganz unrecht. ich versuchs halt scho dort einzusetzen, wo es nur möglich ist. Kann Fehler vermeiden aber auch Probleme bereiten...

 

[stev.glasow]

Stimmt fetzt nicht so,
aber was hältst du davon?

public class Foo{
	private Foo instance = null;
	private int style = 0;
	private Composite comp = null;
	
	public static Foo getInstance(Composite comp, int style){
		if(instance != null){
			if(sytle == Foo.style && comp.equals(Foo.comp)){
				return instance;
			}
			instance.dispose();
		}
		Foo.comp = comp;
		Foo.style = style;
		return (instance = new Foo(blub));
	}
	
	private Foo(blub){
	   ...
	}
	...
}

 

[Bleiglanz]

imho problematisch, die ganze idee taugt einfach nix

stell dir vor ein "client" X holt sich foo

Foo dasIsEs = Foo.getInstance(myStyle, 3)

dann arbeitet er weiter, und während er so dahin arbeitet, ruft eben irgendwoanders in einem Thread jemand

Foo.getInstance(null, 7)

auf und dann?

dann verweist "dasIsEs" auf das "alte Gebilde", das es ja eigentlich nicht mehr geben darf (es kann nur einen geben!); aber X kriegt das ja nicht mit usw. usf.

klingt nach einer schönen Quelle für schwer zu findende Fehler

 

[foobar]

imho problematisch, die ganze idee taugt einfach nix

Was gibt es denn für Alternativen für ein parametrisiertes Singleton? Ausser alle Elemente in einer Map zu cachen.
Denn das Problem habe ich öfters, weiß aber nicht wie ich das am besten lösen kann.

 

[Bleiglanz]

so etwas wie ein

---- "parametriesiertes Singleton"

gibt es einfach nicht, was soll das sein, wie soll das funktionieren?

Warum nicht eine ganz normale Factory (soo teuer ist die Objekterzeugung ja auch nicht, und wenn man die Instanzen immutable macht, dann ist ja alles in Butter)?

 

[helium]

Aber was ringt das?
Dann ist das Singleton fürn Ärmel

wenn es schon ne Instanz gibt und ich ruf getInstance(Parameter) auf, dann legt er mir ne neue an...
und wenn es noch keine gibt und ich ruf dann GetInstance() auf, krieg ich trotzdem null zurück...

oder blick ich das grad net?

Bezog sich das auf meine Version? Falls ja, dann hast du es tatsächlich nicht "geblickt".

mho problematisch, die ganze idee taugt einfach nix

Jo, da muss noch 'ne Schicht zwischen. Du bekommst nicht das tatsächliche Objekt, sondern eins, das immer das Aktuelle abfragt und darauf dann aufruft. Aber das ist aufwändig udn umständlich.


Dennoch würde ich Erstellung und beziehen der "Instanz" trennen:

public class ImplementationHelper {
   private ImplementationHelper instance = null;

   public static ImplementationHelper getInstance ()
   {
      assert (isntance != null);
      return instance;
   }

   public static void create (Bar bar, Baz, baz, Qux qux)
   {
      instance = new ImplementationHelper (bar, baz, qux);
   }

   ImplementationHelper (Bar bar, Baz, baz, Qux qux)
   {
      ...
   }

   void someMethode ()    // eigentliche Implementation der Methoden
   {
      ...
   }
   ...

}

public class Foo {
   private Foo instance = null;

   public static Foo getInstance() { 
      if (instance == null)
         instance = new Foo ();
      return instance;
   } 

   public static void create (Bar bar, Baz, baz, Qux qux)
   {
      ImplementationHelper.create (bar, baz, qux);
   }

   private Foo ()
   { }

   void someMethode ()  // dumme Wrapper
   {
      ImplementationHelper.getInstance().someMethode ();
   }    

   ...
}

Einmal am Anfang und immer wenn sich die Einstellungen ändern ruft man 'Foo.create(...)' auf. Mit 'Foo.getInstance' bekommt man dann eine Instanz mit der man arbeiten kann. Selbst wenn man sie zwischenspeichert und ein anderer Thread oder sonstwas zwischendurch 'Foo.create(...)' aufruft gibt es keine Probleme (syncronize einbauen).

 

[helium]

Dennoch finde ich so eine Lösung irgendwie bescheurt.

 

[Karl]

Hallo,

also irgendwie scheinst Du ja noch nicht zufrieden zu sein :wink: ;
ich pflichte Bleiglanz bei. Die Factory-Methode getInstance() eines Singletons kann man nicht sinnvoll parametrisieren.
Hier zwei Lösungen für zwei unterschiedliche Fälle.

A) Wirklich Singleton? D.h., es gibt es während des Programmlaufs nur eine (festgelegt parametrisierte Instanz)? ->
Dann solltest Du Dir überlegen, die Instanz mit einer entsprechend benannten Methode an einer sinnvollen Stelle zu initialisieren: initialize(...). Diese Methode muss eine Exception werfen, wenn sie ein zweites Mal aufgerufen wird.
Ansonsten brauchst Du noch die unparametrisierte getInstance()-Methode, die allerdings eine Exception wirft, wenn
sie vor der Initialisierung aufgerufen wurde. Als Exception bietet sich die IllegalStateException an.

B) Kein Singleton, sondern es gibt verschieden parametrisierte Instanzen, die allerdings immer wieder verwendet werden sollen. In diesem Fall baust Du einen Cache. Du hast dann eine getXY(...) oder wahlweise createXY(..)-Methode. Wird die Methode aufgerufen, guckst Du nach, ob es die passend parametrisierte Instanz schon gibt; falls ja, wird sie zurück gegeben. Existiert sie noch nicht, wird sie erzeugt, in den Cache gelegt und zurück gegeben.
Das klappt so aber nur für zustandslose oder threadsichere Instanzen. Falls Deine Instanzen immer exklusiv einem
Aufrufer zur gleichen Zeit gehören dürfen (Beispiel aus einem realen Projekt: SimpleDateFormat-Objekte, die aus Perfomance-Gründen gecached werden), dann musst Du sie herausgeben (also erst einmal nicht cachen), eine Methode für die Rückgabe anbieten und sie erst dann in den Cache stecken. Diese Geschichte kann noch durch Pooling erweitert werden, also die Vorhaltung gleich mehrerer Instanzen einer bestimmten sehr gefragten Parametrisierung.

Wenn Du übrigens befürchtest, dass Deine Instanzen zu lange unnötig gecached werden und den Speicher in kritischen Momenten verstopfen würden, dann solltest Du Dir mal die SoftReferences ansehen. Der Garbage Collector
kann die Instanzen dann im Notfall wegschmeißen, wenn der Speicher knapp wird.

Ich denke, bei Dir geht es wohl um Fall B?

Gruß,

Karl