OOP Singleton

[rarofu66]

Kann mir jemand erklären warum das ein Singleton ist?

abstract class Employee {
	abstract void youAreFired();

	static Employee create() {
		return new Employee() {
			public void youAreFired() { 
			}
		};
	}
}

 

[Schandro]

Das ist kein Singleton.

 

[Landei]

Das ist eine Factory, kein Singleton: Fabrikmethode ? Wikipedia

 

[bygones]

[ot]hehe - immer wird man bei der implementierung nicht gefeuert ;-)[/ot]

 

[rarofu66]

So, hier ist die komplette SingletonFactory:

public abstract class Employee {
	abstract void youAreFired();

	private static Employee instance = null;

	public synchronized static Employee create() {
		if (instance == null) {
			instance = new Employee() {
				public void youAreFired() {
				}
			};
		}
		return instance;
	}
	
	public static void main(String[] argv) {
		
		Employee eins = Employee.create();
		Employee zwei = Employee.create();
		System.out.println("eins gleich zwei: " + eins.equals(zwei));
		System.out.println("Hashcode eins: " + eins.hashCode());
		System.out.println("Hashcode zwei: " + zwei.hashCode());
	}
	
}

 

[TryToHelp]

Ja jetzt ist es ein Singleton, aber dein ursprungspost hatte nix mit einem Singleton zu tun ;-)

 

[bone2]

Und jetzt ist es ein Singelton, weil nie mehr als eine Instanz existieren kann. Sobald die einmal konstruiert wurde, wird immer wieder die Selbe zurückgegeben.

 

[FArt]

Und jetzt ist es ein Singelton, weil nie mehr als eine Instanz existieren kann. Sobald die einmal konstruiert wurde, wird immer wieder die Selbe zurückgegeben.

http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef0147e0761e2f970b-pi

 

[SlaterB]

> Und jetzt ist es ein Singelton, weil nie mehr als eine Instanz existieren kann.

genau diese annoyme Implentierung läßt sich nicht erneut erzeugen,
bei Kenntnis des Quellcodes vielleicht in Kopie gleich, aber nicht exakt dieselbe,

von der abstrakten Klasse Employee ist aber nicht die Verhinderung weiterer Instanzen festgeschrieben,
da kann bisher jeder neue Quellcode auch ein Employee-Objekt erzeugen,
da nur Employee als Typ verwendet werden kann, lassen sich andere erzeugte Objekte überall einschleusen wo Employee auftritt,
insofern streng genommen kein Singleton, Ausschluss weiterer Objekte, falls das wichtig ist

es gibt natürlich immer den Positivfall, einfach nur eine statische Variable belegen und verwenden,
kein eigenen Code arbeitet mutwillig dagegen,
hier mit Vorgabe der Implementierung wäre aus schon gegebenfalls große Arbeit, ein zweites Objekt zu erstellen,
schwerer als ein versehentliches [c]new Employee()[/c] irgendwo

----

edit:
@FArt
ich bin mir da nie ganz sicher, vergesse es sicher auch gleich wieder, tue mich schwer im Testen dazu, aber:
würden sich die zwei Instances zweier ClassLoader nacheinander in einer Variable, also in einem bestimmten Typ eines bestimmten ClassLoaders ablegen lassen, oder gibt es da Fehlermeldungen Richtung 'wrong class'?

 

[Volvagia]

Mir fällt gerade auf, du musst den Konstruktor privatisieren, sonst bringt es nichts. In diesen speziellen Beispiel macht es zwar keinen Unterschied, falls mehr als eine Klasse verwendet wird aber schon. Sonst ist eine neue Instanz einfach per new anzulegen. Außerdem ist abstract dabei schlecht, da jede Vererbung eine neue Instanz erzeugt würde.

http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef0147e0761e2f970b-pi

[OT]Wha, das habe ich schon die ganze Zeit in nen FF Tab um es im richtigen Moment posten zu können. ;([/OT]

 

[FArt]

würden sich die zwei Instances zweier ClassLoader nacheinander in einer Variable, also in einem bestimmten Typ eines bestimmten ClassLoaders ablegen lassen

Das gibt eine ClassCastException.

[OT]Wha, das habe ich schon die ganze Zeit in nen FF Tab um es im richtigen Moment posten zu können. ;([/OT]

;-)