Globale vs. Lokale Variablen

[Winnetoupopper]

Hallo!
wenn man nämlich den Konstruktor als protected deklariert kann man noch von dieser Klasse ableiten, was bei einem privaten Konstruktor nicht mehr möglich wäre.

Auch wenn der Topicbezug nur noch durch das Wort "Grundsatzfrage" hergestellt wird, muss ich hier zur Vorsicht aufrufen.
Ein protected Singleton ist schon an sich ne offensive Sache, in Java sogar fatal.

1. Erfordert das Ableiten eines Singletons das -vollkommene- Überschreiben der getInstance-Methode, ein "super" befreit hier nicht.. Das ist sehr offensiv und sollte vor allem in größeren Projekten (> 10 Entwickler) nur mit Vorsicht angewandt werden.

2. In Java wird die Sichtbarkeit "protected" leider als Ableitung von Package betrachtet (OO-technisch natürlich ne Katastrophe!), so kann die erste Direktive eines Singletons (es gibt nur EINS) ausgehebelt werden:

(wie kann man Bilder einfügen?)
http://www.pics.winnetoupopper.de/Multiton.jpg

package de.tutorials;

public class Singleton2Multiton 
{
	public Singleton2Multiton( int pAnzahlSingletons )
	{
		for (int i = 0; i < pAnzahlSingletons; i++)
		{
			new Singleton();
		}
	}
}

gruß Kev

ach ja, synchronized (Singleton.class) ist natürlich godlike, auch ich hatte immer Glück *g*

 

[hpvw]

Nach längerem Nachdenken habe ich gerade meine Zweifel, ob das synchronized an der Stelle richtig schützt.
Müsste es nicht besser vor dem if stehen?
Angenommen Thread1 ruft getInstance auf, es wird eine neue Instanz erzeugt, der Konstruktur braucht aus irgendeinem Grund sehr lange (zum Beispiel verbindet er das Singleton mit einem Sever). Während dessen ruft Thread2 getInstance auf und landet innerhalb des if und wartet bis er auch das Singleton erzeugen darf...
Ich denke, ihr wisst, worauf ich hinaus will?

Gamma sieht zum Erben von Singletons 2 Möglichkeiten:
1. Alle Erben müssen der Superklasse bekannt sein und werden (einmalig beim ersten Aufruf) durch getInstance anhand einer Umgebungsvariablen ausgewählt.
2. Die Erben registrieren sich selbst und werden dadurch bei der Superklasse bekannt. Das bedingt aber, dass sie vor dem ersten Aufruf von getInstance irgendwie ausgeführt werden.

Gerade in Bezug auf Java sieht mir das noch irgendwie nach Würgaround aus.
Ich würde es so lösen:
Zwei getInstance-Methoden
1. getInstance(String type)
2. getInstance()
Die Erben werden in der Superklasse durch einen String identifiziert.
(Man muss natürlich für jeden Erben auch in der Supeklasse rumspielen.)
Es gibt einen default-Singleton (einen Erben oder die Superklasse selbst).
Das Programm erhält so die Möglichkeit, in der main-Methode einen Typ (z.B. einen Algorithmus) zu wählen und im Programm selbst kann immer die einfache getInstance-Methode verwendet werden.
Ist natürlich auch nur ein Workaround.
Das ähnelt sehr stark dem ersten Ansatz von Gamma, aber ich arbeite nicht so gern mit Umgebungsvariablen.

Gruß hpvw

PS: Ich glaube, der Thread ist entführt. Ich hoffe, die Frage wurde bereits ausreichend beantwortet, Steff?

EDIT PPS: Bilder anfügen geht glaube ich über den Button "Anhänge verwalten".

 

[Thomas Darimont]

Hallo!

Schaut euch doch mal diesen Artikel hier an:
//Hier wird sogar "doppelt" synchronisiert
http://www-106.ibm.com/developerworks/java/library/j-dcl.html

und hier:
http://radio.weblogs.com/0122027/stories/2003/10/20/implementingTheSingletonPatternInJava.html

Auch hier wird empfohlen den Kostruktor des Singletons als protected zu deklarieren. Jetzt stellt sich eben die Frage, wie man bei einer Singleton Vererbungshierarchie noch die "Eindeutigkeit" dieses Singletons im System garantieren kann... in dem oben genannten Artikel wird eine Lösugsmöglichkeit (-> eine Art SingletonFactory) beschrieben.

Ein Protected Konstruktor würde auch IMHO das Erzeugen eines Proxy's durch bytecode Manipulation zur Laufzeit erlauben.

1. Erfordert das Ableiten eines Singletons das -vollkommene- Überschreiben der getInstance-Methode, ein "super" befreit hier nicht.. Das ist sehr offensiv und sollte vor allem in größeren Projekten (> 10 Entwickler) nur mit Vorsicht angewandt werden.

Wie willst du denn eine static Methode einer Klasse überschreiben? Du kannst sie zwar redefinieren jedoch ist das dann (in diesem Fall) IMHO kein Überschreiben, weil dann der Mechanismus zur "Methodenfindung zur Laufzeit über die Virtuelle Methoden Tabelle" nicht gegeben ist. -> Keine Polymorphen Methodenaufrufe.

Gruß Tom

 

[steff aka sId]

Noch einmal kurz zurück zum Thema Das mit Singleton etc. ist mir schon klar und auch die benutzung von Konstanten.
Ich hab mich eigentlich nur gefragt ob man beim programmieren einer Gui eher auf Instanzvariablen zurück greifen sollte oder eher Methodenvariablen. Kleine Beispiel:

public class Gui {
   public Gui(){
       buildWindow();
   }

   private void buildWIndow(){
           JFrame myFrame = new JFrame();
           //und jede Menge anderer Kram für die Gui
    }
}

Oder ob man lieber so programmieren sollte:

public class Gui
    JFrame myFrame = null;
    public Gui(){
         buildWindow();
    }

    private void buildWindow(){
          myFrame = new JFrame();
          //jede Menge anderer Kram für die Gui
    }
}

Gruß Steff