# Singletons sind...



## tfa (19. Mrz 2009)

Aus aktuellem Anlass mal eine kleine Umfrage zum Thema Singletons.


----------



## Noctarius (19. Mrz 2009)

Ja ich bekenne mich schuldig, ich benutze sie hin und wieder, wenn sie aus MEINER Sicht Sinn machen.

PS: Jetzt kommen die Anderen wieder, es gibt keine Stellen wo es Sinn macht *gg*


----------



## Spacerat (19. Mrz 2009)

"Hin und wieder" ist mir persönlich ein bissl wenig, "Oft und gerne" dagegen schon wieder zu viel. Sigleton ist eben ein Designpattern, welches wie seine ganzen Kollegen durchaus eine Existenzberechtigung hat. Z.B. bei der Entwicklung eines "Service", wie gerade aktuell: mein "JoalAudioDevice".


----------



## byte (19. Mrz 2009)

Wenn ich Klassen habe, die ich zur Laufzeit nur einmal instanziere, dann benutze ich das Singleton Pattern *nicht*. Dazu sehe ich keine Veranlassung. Wenn ich nur eine Instanz einer Klasse brauche, dann erzeuge ich halt nur eine Instanz der Klasse. Kein Grund, gleich einen privaten Konstruktor einzuführen.

Ich benutze aber manchmal aus Faulheit (genau) *ein* Singleton (und nicht mehr) in meiner Anwendung. An dieses Singleton hänge ich dann alle Informationen, die innerhalb der gesamten Anwendung global verfügbar sein müssen. 
Das aber auch nur, wenn kein DI Container zur Verfügung steht...


----------



## Beni (19. Mrz 2009)

"Überhaupt nicht" wäre dann doch übertrieben, nur halt äusserst selten.
- Wenn mich eine Library dazu zwingt (=weil eine Library zuviele Singletons verwendet, z.B. siehe Java-Swing LookAndFeels. Es ist einfach sinnlos die LookAndFeels _nicht_ in einer globalen Liste zu verwalten).
- Oder wenn eine Resource benötigt wird die unveränderlich ist, wie z.B. eine Map aller Icons die das Programm benutzt.

Ich würde ein Singleton allerdings niemals benutzen nur weil ein Objekt "realistisch gesehen nur einmal notwendig ist". Faulheit ist keine Ausrede für Singletons.


----------



## maki (19. Mrz 2009)

lol @ tfa


----------



## Spacerat (19. Mrz 2009)

Versteh' ich grad' das Pattern nicht? An Singleton stellt sich doch nicht die Frage, ob ich nur eine Instanz einer Klasse brauche, sondern nur die Anforderung, das davon anwendungsweit nur ein Instanz existieren *darf*. Was hat das mit Faulheit zu tun?


----------



## Ebenius (19. Mrz 2009)

Mir fehlt hier eigentlich der Haken "ein Design-Pattern mit Daseinsberechtigung, welches meist falsch und von mir nur selten verwendet wird"  Aus dem Grund hab ich für 2. gestimmt.

Nachtrag: Ich schließe mich also Beni an. Und ich dachte schon, ich bin der einzige der das so sieht. *phew*

Ebenius


----------



## tfa (19. Mrz 2009)

Ebenius hat gesagt.:


> Mir fehlt hier eigentlich der Haken "ein Design-Pattern mit Daseinsberechtigung, welches meist falsch und von mir nur selten verwendet wird"  Aus dem Grund hab ich für 2. gestimmt.


Das wollte ich bei Punkt 2 eigentlich auch noch dazu reinschreiben. Aber jede Umfrage-Option darf höchstens 100 Zeichen lang sein.


----------



## Beni (19. Mrz 2009)

Spacerat hat gesagt.:


> Versteh' ich grad' das Pattern nicht? An Singleton stellt sich doch nicht die Frage, ob ich nur eine Instanz einer Klasse brauche, sondern nur die Anforderung, das davon anwendungsweit nur ein Instanz existieren *darf*. Was hat das mit Faulheit zu tun?



In der Theorie liegst du richtig. Aber in der Praxis sieht man halt leider oft etwas anderes. Ich verweise nocheinmal auf LookAndFeels: es wäre durchaus möglich gewesen, dass jede JComponent ihre LAF vom parent erbt, und man das LAF des Root-Windows halt selbst setzen muss. Wurde nicht so gemacht weil es natürlich einfacher ist...
[highlight=java]UIManager.getColor...[/highlight] 
...zu schreiben als...
[highlight=java]if( parent != null ){
  LookAndFeel feel = parent.getLaF();
  if( feel != null ){
    feel.getColor...
  }
}[/highlight]

(ok, das war etwas böse gesagt. LaF's sind etwas komplizierter, mein Punkt ist trotzdem nicht falsch :bae: )


----------



## Spacerat (19. Mrz 2009)

Beni hat gesagt.:


> In der Theorie liegst du richtig. Aber in der Praxis sieht man halt leider oft etwas anderes. Ich verweise nocheinmal auf LookAndFeels: es wäre durchaus möglich gewesen, dass jede JComponent ihre LAF vom parent erbt, und man das LAF des Root-Windows halt selbst setzen muss. Wurde nicht so gemacht weil es natürlich einfacher ist...
> [highlight=java]UIManager.getColor...[/highlight]
> ...zu schreiben als...
> [highlight=java]if( parent != null ){
> ...


... und nicht zuletzt, weil diese LAFs etwas komplizierter sind, ist doch "UIManager" durchaus sinnvoll. Letztendlich tauscht du in deinem Beispiel Eifer (Gegenteil von Faulheit?) gegen Performance ein ("getColor()"-Rekursiv).


----------



## Spacerat (19. Mrz 2009)

Mal was anderes: Gibt's da 'nen Bug im Board?
Situation:
-In der Tabelle der Themen wird eine Umfrage als "ungelesen" markiert, auch wenn kein neuer Beitrag existiert. Möglicherweise hat sich also nur das Ergebnis geändert.
-Wenn ich mir den Beitrag dann ansehe ist in der Tat das Ergebnis verändert. Auffällig dabei: der Wert für den man selbst gestimmt hat wurde um eins erhöht.
-Dann wechselt man wieder in die Tabelle: Umfrage erscheint als "gelesen"
-nach einem Aktualisieren der Seite, ist es wieder "ungelesen".
So ein Bug würde das Ergebnis extrem verfälschen.


----------



## L-ectron-X (19. Mrz 2009)

Kein Bug sondern Zufall, denke ich.


----------



## didjitalist (19. Mrz 2009)

ich finde zwar nicht, dass singleton ein anti pattern ist, allerdings hab ich es bislang noch nie benötigt. und die fälle, in denen ich bislang singletons gesehen habe, hätten problemlos durch nen haufen statischer methoden ersetzt werden können.

hab nichts gegen das pattern, aber es ist meiner ansicht nach irgendwie überflüssig.


----------



## GilbertGrape (20. Mrz 2009)

Spacerat hat gesagt.:


> Mal was anderes: Gibt's da 'nen Bug im Board?
> Situation:
> -In der Tabelle der Themen wird eine Umfrage als "ungelesen" markiert, auch wenn kein neuer Beitrag existiert. Möglicherweise hat sich also nur das Ergebnis geändert.
> -Wenn ich mir den Beitrag dann ansehe ist in der Tat das Ergebnis verändert. Auffällig dabei: der Wert für den man selbst gestimmt hat wurde um eins erhöht.
> ...



Das hab ich schonmal im Verbesserungs-Thread gesagt. Der Thread bekommt immer ein neuen Editierungszeitpunkt, wenn jemand abgestimmt hat. Ich glaube, dass ausgerechnet der Wert erhöht wurde, für den du gestimmt hast, ist Zufall!


----------



## Beni (20. Mrz 2009)

Spacerat hat gesagt.:


> ... und nicht zuletzt, weil diese LAFs etwas komplizierter sind, ist doch "UIManager" durchaus sinnvoll. Letztendlich tauscht du in deinem Beispiel Eifer (Gegenteil von Faulheit?) gegen Performance ein ("getColor()"-Rekursiv).



Dazu möchte ich 2 Dinge sagen.

Erstens. Dein Argument ist ein "praktisches Argument", meines ein "theoretisches Argument". Je nachdem was für Ziele man hat muss man eines stärker als das andere gewichten. Wenn wir über gutes Softwaredesign sprechen wollen, befinden wir uns auf der Ebene der (grauen?) Theorie.

Zweitens. Ich hab auch schon eine Library geschrieben die etwas ähnliches wie LAFs anbietet, aber dort auf das Singleton verzichtet. Was ich davon gelernt habe: es ist möglich, es ist nicht so schwierig wie man vielleicht befürchtet, die Performance geht nicht merklich zurück; es wäre auch für LAFs möglich.

[Edit: und langsam benötige ich ein anderes Beispiel, wird etwas einseitig...]


----------



## byte (20. Mrz 2009)

Beni hat gesagt.:


> Wenn wir über gutes Softwaredesign sprechen wollen, befinden wir uns auf der Ebene der (grauen?) Theorie.



Das sehe ich anders. OO-Design soll praktische Probleme lösen, z.B. die Wartbarkeit oder Qualität (Testbarkeit) der Software erhöhen. Wenn man keine praktischen Ziele verfolgt, könnte man sich das Thema schenken. Niemand zahlt Geld für die Lösung von Problemen, die bloß in der blanken Theorie existieren aber keinen praktischen Bezug haben.


----------



## Ebenius (20. Mrz 2009)

byto hat gesagt.:


> Niemand zahlt Geld für die Lösung von Problemen, die bloß in der blanken Theorie existieren aber keinen praktischen Bezug haben.


Juchu, dann können wir ja die Hälfte aller Universitätsmitglieder entlassen?

Hab nen Clown gefrühstückt. Schmeckte komisch.


----------



## byte (20. Mrz 2009)

Auch Forschungsprojekte an Unis haben idR einen wirtschaftlichen Hintergrund. Irgendwo müssen die Forschungsgelder ja herkommen. Die Wirtschaftlichkeit wird da nur auf einen größeren Zeitraum angesetzt.


----------



## tfa (20. Mrz 2009)

Was wohl nicht gilt für "Laberfächer" wie Philosophie, Astrophysik, Kosmologie, Altertumsforschung etc.
Sagen wir, niemand zahlt _freiwillig_ Geld für Lösungen von Problemen, die nur in der Theorie existieren. Der Steuerzahler wird's richten.


----------



## Ebenius (20. Mrz 2009)

Mein Orakel informiert mich gerade, dass in diesem Thema gleich über die Wirtschaftlichkeit der Untersuchungen eines pfeifenden und malenden Orang-Utans diskutiert wird. Ich glaub mein Schwein pfeift. Schon wieder der Frühstücksclown. Der ist schuld.

Ebenius


----------



## thE_29 (20. Mrz 2009)

Ich nutze das Singleton Pattern als PoolConnection Objekt!

Da brauche ich im Konstruktor einmal die Settings einlesen und erzeuge/reservie dann die Verbindungen. Es greifen 20 verschiedene Klassen drauf zu.
Also warum sollten die alle dieses PoolConnection Objekt neu instanzieren wenns nicht nötig ist?!

Oder wie würdet ihr das lösen, wenn euch das Pattern nicht gefällt?


----------



## tfa (20. Mrz 2009)

thE_29 hat gesagt.:


> Oder wie würdet ihr das lösen, wenn euch das Pattern nicht gefällt?


Mit Spring über Dependency Injection das Pool-Objekt in alle 20 Klassen, in denen es gebraucht wird, injizieren. Ganz einfach und leicht zu modifizieren.


----------



## mikachu (20. Mrz 2009)

Es kommt IMO ganz drauf an, ob sich der Singleton irgendwas "merken" soll oder nicht.
Wenn ja, dann ist es gerechtfertigt, wenn aber nicht, dann setze ich nur statische Methoden ein.

Das ist wie gesagt sehr szenario-abhängig und so allgemein kann man da IMO keine zu 100% zutreffende Auswertung geben.

Die Auswahl bei der Umfrage ist auch ziemlich grob strukturiert, wie es einige Vorposter (*gg*) schon zu Wort gebracht haben. Eine feinere Granularität wäre da angebracht, würde aber auch abschrecken ;-).

Ab und an nutze ich Singletons... wie gesagt.


----------



## Developer_X (20. Mrz 2009)

ich finde es erfreulich, wenn ich einen Button anklicke, und dann eine geräusch höre, ich find das eigentlich ganz toll,,,
außerdem wirkt das programm finde ich besser, und professioneller


----------



## maki (20. Mrz 2009)

> Es kommt IMO ganz drauf an, ob sich der Singleton irgendwas "merken" soll oder nicht.
> Wenn ja, dann ist es gerechtfertigt, wenn aber nicht, dann setze ich nur statische Methoden ein.


Naja, das reicht noch nicht.
Ein Singleton hat immer einen Zustand ("etwas merken"), sonst wäre es keines 
Aber es gibt mehr Alternativen als "Singleton oder. statische Methoden".


----------



## mikachu (20. Mrz 2009)

Naja, ich habe auch schon Quellcodes gesehen, wo auch ein Singleton verwendet wurde, welcher aber keine Zustände hatte ;-).
Eben von jemandem, der Hardcore-Singleton-User ist *gg*

Aber mal ne freche Frage: was gibt es da noch für Alternativen!?


----------



## maki (20. Mrz 2009)

mikachu hat gesagt.:


> Naja, ich habe auch schon Quellcodes gesehen, wo auch ein Singleton verwendet wurde, welcher aber keine Zustände hatte ;-).
> Eben von jemandem, der Hardcore-Singleton-User ist *gg*


Nun, das ist wirklich sinnfrei 



mikachu hat gesagt.:


> Aber mal ne freche Frage: was gibt es da noch für Alternativen!?


Die Objekte die eine Referenz auf das ehem. Singleton brauchen bekommen eben eine, per Setterparameter, oder per Konstruktorparameter, oder eben nur als Methodenparameter.
Sehr einfach zu bewerkstelligen mit DI Frameworks (Spring, Guice, ja sogar EJB3 bietet diese Möglichkeit).
Hat eben den Vorteil dass man entscheiden kann (zB. fürs Testen) was verwendet werden soll, denn mit GoF Singletons ist das nicht mehr möglich, da diese "festverdrahtet" sind.


----------



## tfa (20. Mrz 2009)

maki hat gesagt.:


> Ein Singleton hat immer einen Zustand ("etwas merken"), sonst wäre es keines


Wo steht das schon wieder?
Ein Kühlschrank am Südpol ist Blödsinn, aber trotzdem ein Kühlschrank.


----------



## mikachu (20. Mrz 2009)

Argh, da ist wieder das Wort "Frameworks"... damit hab ich mir noch nicht näher mit beschäftigt... wird aber langsam mal Zeit, wie ich das so sehe ;-).

Vielen Dank! *mit oder ohne Ironie???*


----------



## maki (20. Mrz 2009)

tfa hat gesagt.:


> Wo steht das schon wieder?
> Ein Kühlschrank am Südpol ist Blödsinn, aber trotzdem ein Kühlschrank.


Schon klar, aber wer Singletons ohne Zustand baut, frisst kleine Kinder, ääääääääähh.... hat keine Ausrede welche zu verwenden


----------



## SebiB90 (20. Mrz 2009)

tfa hat gesagt.:


> Mit Spring über Dependency Injection das Pool-Objekt in alle 20 Klassen, in denen es gebraucht wird, injizieren. Ganz einfach und leicht zu modifizieren.


Was ist aber wenn es ein nicht so großes Programm ist und der Einsatz von Spring für das Projekt total übertrieben wäre?


----------



## Wildcard (20. Mrz 2009)

SebiB90 hat gesagt.:


> Was ist aber wenn es ein nicht so großes Programm ist und der Einsatz von Spring für das Projekt total übertrieben wäre?


Was ist, wenn ein Teil deiner Applikation mal in einem größeren Framework verwendet werden soll?
Man vergisst gerne, Singletons in Java gibt es nicht, da statisch nur pro Classloader Hierarchie einzigartig ist. Da Container mit getrennten Classloadern Hierarchien aber immer wichtiger werden (OSGi, Application Server,...), funktioniert das mit dem Singleton nicht mehr.
Wenn man ein Singleton also als Pattern und nicht als Anti-Pattern verwendet hat (sprich: nicht 'es gibt nur eine Instanz', sondern 'es *darf* nur eine Instanz geben'), dann ist der geschriebene Code schon alleine dadurch unflexibel, das er in größeren Anwendungen nicht mehr richtig funktioniert.
Ich zitiere mal Wiki, denn da steckt viel wahres drin:


> Das korrekte Design von Singletons ist schwierig – in der Regel schwieriger als Designs ohne Singletons.


----------



## byte (21. Mrz 2009)

SebiB90 hat gesagt.:


> Was ist aber wenn es ein nicht so großes Programm ist und der Einsatz von Spring für das Projekt total übertrieben wäre?



Spring Core ist ein 280 kB kleines Jar-File. Das würde ich in *jedem *Projekt integrieren. :bahnhof:


----------



## SlaterB (21. Mrz 2009)

Wildcard hat gesagt.:


> Man vergisst gerne, Singletons in Java gibt es nicht, da statisch nur pro Classloader Hierarchie einzigartig ist.


gilt sowas übrigens auch für Enums? dann hätte man ja ganz andere Probleme oder sollen alle Enum-Mengen per Spring übergeben werden?


----------



## byte (21. Mrz 2009)

Es gibt in Spring keine Singletons nach Definition der GOF.


----------



## SlaterB (21. Mrz 2009)

hmm, da du vor mir als letzter geantwortet hast, muss sich das ja auf meinen Beitrag beziehen,

sind Enums auch Singletons oder was meinst du?


----------



## Noctarius (21. Mrz 2009)

Enums sind Bunches of Singletons


----------



## SebiB90 (21. Mrz 2009)

byto hat gesagt.:


> Spring Core ist ein 280 kB kleines Jar-File. Das würde ich in *jedem *Projekt integrieren. :bahnhof:



Hm..ok...kenn mich mit Spring noch kaum aus und weiß nicht welche Jars für welche Funktionen gebraucht werden. Mein bisheriger Kontakt mit Spring beschränkt sich auf 3 Wochen Praktikum, in denen ich an einem Projekt gearbeitet hab, wo es eingesetzt wurde. Selbst habe ich mit Spring nichts gemacht, nur es versucht zu verstehen (wusste vorher nichtmal das etwas wie DI gibt). Und in dem Projekt wurden mit Spring eigentlich nur die Remote-Beans in ein Singleton im Client reingepackt und über das Singleton wurde dann auf diese zugegriffen. Und ich frag mich wie ihr überall die DI macht, da dann ja auch alle Models der GUI mit Spring erstellt werden müssten. Ich weiß, es wäre viel arbeit, aber ich fände es cool, wenn jemand mal ein kleines / mittelgroßes Projekt mit Spring (und vllt anderen Interessanten Sachen) entwickelt und das Schritt für Schritt im Blog erklärt


----------



## Spacerat (21. Mrz 2009)

Noctarius hat gesagt.:


> Enums sind Bunches of Singletons


... Öhm... nö!
	
	
	
	





```
public enum Type {
A, B, C, D
}
```
sind 4 Instanzen (A, B, C, D) der Klasse Type!


----------



## thE_29 (23. Mrz 2009)

@tfa: Was ist, wenn das aber keine WebApp ist sondern eine Standalone die mehere Verbindungen braucht? Soll ich da jetzt das SpringFramework reingeben?

Außerdem was ist wenn ich es im gleichen Programm in verschiedenen Klassen brauche? Dann kann ich entweder jeder Klasse eine Instanz der Hauptklasse mitübergeben oder irgendwo was static machen.
Oder was empfehlt ihr bei diesem Problem?


----------



## maki (23. Mrz 2009)

thE_29 hat gesagt.:


> @tfa: Was ist, wenn das aber keine WebApp ist sondern eine Standalone die mehere Verbindungen braucht? Soll ich da jetzt das SpringFramework reingeben?


Spring braucht keine WebApp, geht immer .



> Außerdem was ist wenn ich es im gleichen Programm in verschiedenen Klassen brauche? Dann kann ich entweder jeder Klasse eine Instanz der Hauptklasse mitübergeben oder irgendwo was static machen.
> Oder was empfehlt ihr bei diesem Problem?


Wieder kann Spring (oder ein anderes DI Framework) verwendet werden.

Der DI Teil von Spring ist leicht zu erlernen und spart dazu noch Code.


----------



## byte (23. Mrz 2009)

thE_29 hat gesagt.:


> Da brauche ich im Konstruktor einmal die Settings einlesen und erzeuge/reservie dann die Verbindungen. Es greifen 20 verschiedene Klassen drauf zu.
> Also warum sollten die alle dieses PoolConnection Objekt neu instanzieren wenns nicht nötig ist?!
> 
> Oder wie würdet ihr das lösen, wenn euch das Pattern nicht gefällt?



Das ist doch genau die Sache, über die wir die ganze Zeit sprechen. Du hast eine Klasse, die Du zur Laufzeit einmal instanzierst und an verschiedenen Stellen im Code auf diese Instanz zugreifen musst. 

Du benutzt nun das Singleton Pattern, um Dir das Übergeben der Referenzen auf dieses Objekt zu sparen. Das ist aber aus diversen schon angesprochenen Gründen schlecht. 

Statt an x Stellen im Code ConnectionPool.getInstance().blablub() aufzurufen, solltest Du beim Initialisieren der Objekte jedem Objekt explizit eine Referenz auf den ConnectionPool geben.

Wie maki schon sagte, nehmen Dir Dependancy Injection Frameworks wie Spring da viel Arbeit ab.


----------



## tfa (23. Mrz 2009)

Richtig. Spring ist in normalen Anwendungen auch sinnvoll. Gerade ein ("Singleton"-)Objekt in verschiedenen Klassen gebraucht wird, spart man sich durch DI viel Schreibkram. Vielleicht blogge ich mal ein Bespiel, wenn ich Zeit finde.


----------



## SlaterB (23. Mrz 2009)

also an der Schreibarbeit kann man nun glaube ich am wenigsten sparen, wenn ich mich recht erinnere  ,
neben der externen XML-Konfiguration brauch doch jede fragliche Klasse ein Klassenattribut + setter + getter,

wie soll das mit Singleton mehr werden, da könnte man ja auch ein Attribut + getter mit Lazy-Abfrage der statischen getInstance() schreiben, 
spart den setter und kann dann im Code wie bei Spring
> getPool().blablub()
schreiben und nicht unbedingt 
> ConnectionPool.getInstance().blablub()
falls nicht gewünscht (an manchen Stellen allerdings vielleicht doch 'kürzer' als Attribut + getter, man hätte die Wahl)

soviel nur zur Schreibarbeit, soll sonst keine Unterstützung des Singletons sein, und berücksichtigt nicht den Aufwand für Umbau für Tests oder so


----------



## maki (23. Mrz 2009)

SlaterB,

getter braucht man in so einem Fall keine, ein setter reicht, und der macht nix weiter als den Parameter dem Attribut zuweisen.

public void setWhatever(final Whatever whatever) {
    this.whatever = whatever);
}

Der setter ersetzt die Aufrufe 

> getPool().blablub()
bzw.
> ConnectionPool.getInstance().blablub()

vollständig, denn danach nutzt einfach jede Klasse die whatever braucht es direkt:
whatever.doSomething();

Der XML Code, also die Spring config besteht für so einen einfachen Fall (Singleton ersetzen) zum Grösstenteil aus der Schema referenz.

Nebenbei bekommt man auch ein besseres Design der Anwendung, denn nun ist diese Abhängigkeit nicht mehr implizit, sondern explizit.


----------



## tfa (23. Mrz 2009)

Du brauchst pro Singleton und verwendeter Klasse eine Zeile XML (okay, XML ist Mist, aber eine Zeile!), der Form

[HIGHLIGHT="xml"]<bean id="nameDerBean" class="klasse.der.bean" />[/HIGHLIGHT]

Getter und Setter brauchst du nicht, wenn du mit Annotationen arbeitest (Getter sowieso nicht):

[HIGHLIGHT="Java"]@Autowired
private KlasseDerBean meineBean;[/HIGHLIGHT]
Fertig.

Wenn du später beispielsweise doch eine andere Implementierung willst, oder für Unittests ein Mock-Objekt haben möchtest, was machst du dann bei statischen, festverdrahteten Singletons? Ist das vielleicht doch mehr Schreibarbeit?


----------



## maki (23. Mrz 2009)

>> Getter und Setter brauchst du nicht, wenn du mit Annotationen arbeitest:

auch wieder richtig..


----------



## SlaterB (23. Mrz 2009)

> Wenn du später beispielsweise doch eine andere Implementierung willst, oder für Unittests ein Mock-Objekt haben möchtest, was machst du dann bei statischen, festverdrahteten Singletons? Ist das vielleicht doch mehr Schreibarbeit?

hehe, hab ich doch extra vorsorglich dazugeschrieben, mehr kann man doch nicht erwarten oder? 

ok, ohne setter/ getter, ist mir neu, 
hätte ich für derart strukturierte Programmierung nicht gedacht, aber mag sein


----------



## tfa (23. Mrz 2009)

SlaterB hat gesagt.:


> hehe, hab ich doch extra vorsorglich dazugeschrieben, mehr kann man doch nicht erwarten oder?


Stimmt. Hab ich übersehen. :rtfm:


----------



## thE_29 (23. Mrz 2009)

Oho! Wenn du mal Zeit hast, bitte eine Erleuterung posten! Oder auch ein anderes Injection Framework. Problem bei mir ist ja auch das ich Java 1.4 entwickle! Stört das irgendwie?

Und warum sollten bei JUnit Tests Singleton Patterns nicht funktionieren?!

Bei mir sieht getInstance nach ob die instance null ist, wenn ja ruf den internen Konstruktor auf.


----------



## Ebenius (23. Mrz 2009)

Ist das Thema eigentlich schon immer im Anfänger-Forum? Ich verschieb's mal.

Ebenius


----------



## maki (23. Mrz 2009)

>> Und warum sollten bei JUnit Tests Singleton Patterns nicht funktionieren?!

Schon mal versucht für einen Unittest die Implementierung des GoF Singletons auszustauschen? -> Geht nicht!
In der Lage zu sein die echten Implementierungen (hier: Singleton) gegen andere auszutauschen ist die Grundvorraussetzung für isolierte Tests (Unittests).

Spring bis einschliesslich Version 2.5 läuft auf Java 1.4, erst Spring 3 wird (wenn es mal draussen ist) Java 5 vorraussetzen.


----------



## thE_29 (23. Mrz 2009)

Meinst du sowas hier mit GoF Singletons? Archive Hive  Blog Archive  GoF: Singleton
Und warum sollte ich sowas bei Tests austauschen?! Wenn ich teste, will ich das 1:1 testen und nicht für einen Test Dinge abändern die nur im Test so sind und beim echten Durchlauf nicht..


----------



## Ebenius (23. Mrz 2009)

thE_29 hat gesagt.:


> Meinst du sowas hier mit GoF Singletons? Archive Hive  Blog Archive  GoF: Singleton
> Und warum sollte ich sowas bei Tests austauschen?! Wenn ich teste, will ich das 1:1 testen und nicht für einen Test Dinge abändern die nur im Test so sind und beim echten Durchlauf nicht..


*Unit*Tests testen eben Einheiten. Das bedeutet, der Testgegenstand sollte weitestgehend von seiner Umgebung isoliert getestet werden können.

Ebenius


----------



## maki (23. Mrz 2009)

thE_29 hat gesagt.:


> Meinst du sowas hier mit GoF Singletons? Archive Hive  Blog Archive  GoF: Singleton


Eben das "klassische" Singleton



> Und warum sollte ich sowas bei Tests austauschen?! Wenn ich teste, will ich das 1:1 testen und nicht für einen Test Dinge abändern die nur im Test so sind und beim echten Durchlauf nicht..


Nein, nicht wirklich.

Unittest vs. Integrationstest

Unittests testen das sog. SUT (System/Subject under Test) in Isolation.
D.h. du testest eine deiner Klassen, nicht deine ganze Anwendung 
Echte Unittests (keine Integrationstests, zB. DAO Tests)  brauchen ca. 10-20% der Gesamtentwicklungszeit, wenn das Design der Anwendung stimmt, ansonsten dreht sich das Verhältnis mal schnell um...

Sieh dir mal JUnit an, ist 'ne gute Sache


----------



## thE_29 (23. Mrz 2009)

Jo, aber warum werden diese Einheiten nicht funktionieren? Probiert man auf das Singleton zuzugreifen instanziert es sich. Solange in dem Singleton keine Abhängigkeit zu etwas ist, was in dem UnitTest nicht ist, gibts da ja kein Problem. 
Und meine Singletons sind ja da um komplett alleine zu arbeiten, da ich ja sonst einen Konstruktor mit einer Instanz, etc.. übergeben sollte und somit wäre das kein Singleton oder falsch angedacht.

PS.: Ich setze UnitTests für ein paar Rechnungen ein und die greifen sauber auf Singletons zu, da diese ihrer Properties zentral (registry, bzw. unter Linux eine Datei) auslesen und dies komplett ohne einer anderen Instanz.


----------



## Ebenius (23. Mrz 2009)

Man würde aber bei einem UnitTest unter Umständen das Singleton austauschen wollen, gegen eines welches definierte Zustände hat, statt die Instanz zu nutzen, die alle anderen benutzen sollen.

Ebenius


----------



## maki (23. Mrz 2009)

thE_29 hat gesagt.:


> Jo, aber warum werden diese Einheiten nicht funktionieren?


Das nennt man "Bugs".

Mal ernsthaft, GoF Singletons lassen sich nunmal nicht austauschen zum Testen, sind fest verdrahtet.
Wenn man sie nicht austauschen kann, kann man die davon abhängigen Klassen nicht isoliert testen.
Mit Aufwand kann man das zwar, aber dann schreibt man länger am Test als am Produktivcode, ist nicht sinnvoll.



> PS.: Ich setze UnitTests für ein paar Rechnungen ein und die greifen sauber auf Singletons zu, da diese ihrer Properties zentral (registry, bzw. unter Linux eine Datei) auslesen und dies komplett ohne einer anderen Instanz.


Greifst du auf auf das Singleton zu oder die Klasse die du testest? 

Versuche dein Singleton mal durch ein Mockobjekt auszutauschen


----------



## byte (23. Mrz 2009)

Wenn Du innerhalb eines Singletons komplexe Berechnungen durchführst oder gar Resourcen bindest (z.B. durch Datenbankzugriffe), dann ist es ratsam, das Singleton einmal separat zu testen und in allen weiteren Tests statt des richtigen Singletons ein Mock-Objekt zu benutzen.

Das hat schon den ganz einfachen Nutzen, dass die Tests dadurch schneller durchlaufen. Angenommen Du schreibst Tests für 10 Methoden, die alle noch eine Methode im Singleton aufrufen. Dann testest Du implizit 10mal die Methode im Singleton. Das wird schnell sehr imperformant. Und wenn der Test mal fehl schlägt, musst Du erstmal gucken, ob der Fehler nun in der eigentlich zu testenden Methode liegt oder doch in Deinem Singleton.


----------



## thE_29 (23. Mrz 2009)

AAAA 
Jetzt verstehe ich euch! Sagen wir mal, wir wollen testen ob er keine Connections erzeugen kann!
Jetzt muss ich mein Singleton entweder abändern oder sonstwas machen um diesen Fall zu testen!

Ist das der Fall den ihr meint?
Könnte man mit einem Interface versehen und bisi abändern, aber da wird wohl so ein DI Framework besser sein!

Ist das sowas hier in der Art: Adding Interface Injection to Spring - Spring Discuss - Confluence
?
Oder habt ihr wo ein besseres Bsp/Anleitung?

@byto: Was ist den ein Mock Objekt? Und wie soll ich eine Connection testen ohne die Connection zurückzugeben? Das Statment würde ohne Connection mal derbe blöd aus der Wäsche gucken


----------



## byte (23. Mrz 2009)

thE_29 hat gesagt.:


> @byto: Was ist den ein Mock Objekt? Und wie soll ich eine Connection testen ohne die Connection zurückzugeben? Das Statment würde ohne Connection mal derbe blöd aus der Wäsche gucken



http://de.wikipedia.org/wiki/Mock-Objekt

Redest Du von einer Datenbank Connection? Die schreibt man ja nicht selbst und muss sie daher auch nicht testen. 

Man schreibt aber uU DAOs, die eine Connection benutzen, um Objekte aus der Datenbank zu lesen. In diesem Fall schreibe ich mir einen DAO-Test, der mit einer Test-Connection auf eine Test-Datenbank geht.

Wenn ich dann Tests schreibe zu Klassen, die dieses DAO benutzen, dann schreibe ich mir im Idealfall ein DAO-Mock, das nicht auf die Datenbank geht, sondern stattdessen reproduzierbare Testdaten zurückliefert.

Somit teste ich das DAO also nicht doppelt und die Tests laufen schneller durch.


----------



## maki (23. Mrz 2009)

thE_29 hat gesagt.:


> AAAA
> Jetzt verstehe ich euch! Sagen wir mal, wir wollen testen ob er keine Connections erzeugen kann!
> Jetzt muss ich mein Singleton entweder abändern oder sonstwas machen um diesen Fall zu testen!
> 
> ...


DAO Tests sind leider ein schlechtes Beispiel, da es sich um Integrationstests handelt welche immer sehr aufwändig sind und sich nicht ohne irgendeine Art von (Ersatz) DB testen lassen.

Mockobjekte sind Objekte denen ich sagen kann welches Interface sie implementieren und wie sich sich zu verhalten haben.
Damit kann ich die Klassen entkoppeln und teste nur das SUT, was wiederum zu stabileren tests führt weil ich ja in einem Unitest dann nicht mehr abhängig bin von der Implementierung  von einer Klasse die ich eigentlich gar nicht testen will.
"Mock roles not objects" heisst hier der Leitspruch.

Tests die schlecht geschrieben sind (fragil, da hohe abhängigkeiten etc.) sind wie ein Klotz am Bein der mit jedem Schritt schwerer wird, stell dir mal vor du hast eine Anwendung mit vielen tests und du änderst jetzt die Implementierung einer einzigen Klasse, plötzlich schlagen ein Dutzend Tests fehl und müssen allesamt korrigiert werden... das führt dazu das jede zusätzliche Änderung immer mehr und mehr Aufwand verursacht, war nicht im Sinne des Erfinders


----------



## thE_29 (23. Mrz 2009)

Tjo, ich verwende mein Singelton Pattern ja nur bei dem PoolConnection Zeugs  Bzw, andere Verbindungen zu C++ Services wo ich halt auf die Verbindung reagieren muss. Obwohl dort könnte ich immer sagen, es ging gut 

Naja, wenn mir jemand das mit Spring oder einem anderen DI super erklären würde, dann würde ich auch keine Singletons mehr einsetzen


----------



## byte (23. Mrz 2009)

Wir können Dir nur die Tür zeigen. Durchgehen musst Du alleine.


----------



## thE_29 (23. Mrz 2009)

Du Schelm du 
Hab halt gehofft das wer wo einen Link hat wo es gleich an einem Bsp schön und schnell erklärt wird.


----------



## byte (23. Mrz 2009)

Guck Dir halt die Referenz Doku an. Die ist super!


----------



## thE_29 (23. Mrz 2009)

Ok, dann mache ich das in ein paar Jahren wenn ich mal Zeit habe mich durch Dokus durchzuwühlen..


----------



## byte (23. Mrz 2009)

Wie lernst Du dazu, wenn Du nix liest? 

Gar nicht?


----------



## thE_29 (23. Mrz 2009)

Ich lerne nur neue Dinge die ich brauche oder die, die mich privat interessieren. Da ich privat kaum Java mache kommt da also außerhalb der Firma kaum was neues dazu (dafür halt lauter andere Sachen). Aber um Dinge die ich nicht wirklich brauche und nur NiceToHave sind, kümmere ich mich erst in 2ter Linie!

Dadurch das mir hier ja niemand auch nur einen Link gleich zum wichtigstens posten wollte und ich mich nicht durch die lange Doku wühlen will, habe ich dafür keine Zeit.

Wenn das hier soviele benutzen frage ich mich was da so schwer ist das kurz zusammenzufassen, wenn es denn doch so wenig Schreibarbeit ist und man sich eigentlich was ersparen sollte.


----------



## byte (23. Mrz 2009)

Es gibt kaum Libraries, wo es mehr Infos zu im Netz gibt, als zum Spring Framework. Wenn Dir das nicht reicht bzw. Du keinen Bock hast, selbst kurz zu googlen, dann tuts mir leid. :bahnhof:


----------



## thE_29 (23. Mrz 2009)

Najo, anscheinend ist es zuviel verlangt mir zu helfen..

Wenn jetzt ein User XYZ fragen würde, würde man einen Link posten und eventuell ein Bsp! Mir sagt man aber "google danach"..

Und nicht nur du brauchst dich hier angesprochen fühlen. Jeder hier im Thread! Es sagt jeder Singleton sind böse und DI ist besser, aber Bsp gibts keine...
Stattdessen wird man auf ein Framework vertröstet das einfach riesig ist. Mache ich das nächste mal auch wenn jemand fragt wie man zB eine Datei ausliest. Sag ich einfach Java kann das such mal in der Doc danach, findet man ja über google..

Mir würde ja schon der Link zu dem ganzen Bereich im Spring Framework reichen, ich finde da immer nur How To: Dependency Injection with Spring.NET oder was mit AspectJ und Spring, etc...

Wenns den soviele hier einsetzen, ist es zuviel verlangt da hinzuverlinken?


----------



## Ebenius (23. Mrz 2009)

thE_29 hat gesagt.:


> Es sagt *jeder* Singleton sind böse und DI ist besser, aber Bsp gibts keine...


Ich habe das nie gesagt.  Und die Abstimmung wiederspricht dem ebenfalls.



thE_29 hat gesagt.:


> Wenns den soviele hier einsetzen, ist es zuviel verlangt da hinzuverlinken?


Glaube nicht, dass das so viele hier einsetzen. Ich schonmal nicht.

Ebenius


----------



## thE_29 (23. Mrz 2009)

Oho!
Also sind Singletons doch nicht böse? Oder jeder weiß, dass sie böse sind, nutzt sie aber trotzdem, weil Byto keinem DI mit Spring erklären will


----------



## Ebenius (23. Mrz 2009)

thE_29 hat gesagt.:


> Also sind Singletons doch nicht böse? Oder jeder weiß, dass sie böse sind, nutzt sie aber trotzdem, weil Byto keinem DI mit Spring erklären will


Du hattest bestimmt auch keine Zeit / keine Lust, die vorangegangenen Diskussionen in diesem Thema und das im Eingangsthema verknüpfte Thema zu lesen, oder? Ansonsten hättest Du mitbekommen, dass da schon einige Diskussion zu dem Thema stattfand. 

Ebenius


----------



## thE_29 (23. Mrz 2009)

Naja, den Thread hier habe ich zumindest gelesen...
Finds halt lustig, dass die Singletons verpöhnt sind, aber trotzdem genutzt werden 

Ich guck mir mal den anderen Thread an!

Oho, also der Zugriff auf den Statischen Kontext ist nicht gern gesehen.. Najo.. *weiterles*


----------



## byte (23. Mrz 2009)

thE_29 hat gesagt.:


> Wenns den soviele hier einsetzen, ist es zuviel verlangt da hinzuverlinken?


Weil Du es bist: Chapter3.The IoC container


----------



## tfa (24. Mrz 2009)

Ich hab mal ein Beispiel zur DI gebloggt.


----------



## thE_29 (24. Mrz 2009)

So, habe jetzt dein Bsp durch und mir sogar Google Guice angeschaut!

Fazit: UNBRAUCHBAR!!!

Jedesmal wenn ich mir den Context lade mit dem Befehl hier:
    ApplicationContext ctx = new ClassPathXmlApplicationContext("testspring.xml");
Oder bei guice mit dem hier:
    Injector injector = Guice.createInjector(new PoolConnection());

Werden die Klassen drin neu erzeugt! Somit ist das ganze mehr kein Singleton, weil der mir immer ne neue Instanz anlegt. Und wie geht das ganze eigentlich mit Java 1.4 wenn ich keine Annotations habe?

Das Google Ding geht sogar einfacher konfigurieren, nur legt das noch mehr Instanzen von dem Objekt an als Spring. Aber ich glaube da habe ich was falsch gemacht! Lustig ist sowieso das deren Doku nur noch sinnlos ist. Es wird zuerst Code Injection per Hand erklärt und wie man die Klassen erstellt! Dann werden die Klassen mit Guice Code Injection umgebaut, aber wie man diese Klassen jetzt instanziert, dass wird nirgends erklärt. Man hat aufeinmal nen Konstruktor wo man das Bean Objekt übergeben sollte, aber wie das jetzt instanziert wird oder geladen wird, das steht nirgends...

Desweiteren weil manche einen statischen Zugriff nicht mögen, dem hilft Guice nicht wirklich, weil der Injector auch static ist!


----------



## byte (24. Mrz 2009)

> Fazit: UNBRAUCHBAR!!!






thE_29 hat gesagt.:


> Jedesmal wenn ich mir den Context lade mit dem Befehl hier:
> ApplicationContext ctx = new ClassPathXmlApplicationContext("testspring.xml");
> Werden die Klassen drin neu erzeugt!


So ist es auch gedacht. Den ApplicationContext erzeugt man idR *einmal *und *nicht jedesmal*.


----------



## thE_29 (24. Mrz 2009)

Aha und dann muss ich jeder meine Klasse die eine Verbindung zur Datenbank braucht (also PoolConnection) die Instanz von dem ApplicationContext übergeben?

Mir gehts aber ja darum, dass ich nix meiner Klasse übergeben will.

Es ist halt austauschbarer und man kann mehrere Dinge ja drinnen speichern, aber in meinem Fall ist das nur
1. mehr Schreibarbeit
2. mehr Libraries die keiner braucht (ich kann spring rein hängen und dann noch das logging framework)
3. muss wieder eine Instanz quer durch alle Klassen reichen.

Da habe ich mein Singleton Pattern zwecks der Datenbankverbindung und da brauche ich nix niemanden mitübergeben.


----------



## byte (24. Mrz 2009)

thE_29 hat gesagt.:


> Aha und dann muss ich jeder meine Klasse die eine Verbindung zur Datenbank braucht (also PoolConnection) die Instanz von dem ApplicationContext übergeben?



Nein. 

Du lässt die Objekte durch Spring erzeugen und konfigurierst die Referenz auf die PoolConnection-Bean per XML oder per @Autowired.

Es gibt sogar eine Möglichkeit, die Objekte proprietär per new Operator zu erzeugen und trotzdem von der Dependancy Injection zu profitieren (siehe @Configurable in der Doku). Das ganze funktioniert per AspectJ Load-Time Weaving (Bytecode Instrumentation).


----------



## thE_29 (24. Mrz 2009)

So, gerade Beitrag verfasst und beim Schreiben bin ich draufgekommen, wie das ganze einen Sinn ergibt 

Die Klassen werden ja alle nur einmal erstellt (WebService) und dort wo sie erstellt werden, wird einmal der ApplicationContext geladen und dann die Klassen erstellt! 

Jedenfalls geht das ganze dann mit guice leichter 

Achja und bei mir (also Standalone App) ist das ganze unbrauchbar, da ich dynamisch Jar Files lade. Also es wird eine Klasse nicht nur einmal erstellt, sondern manchmal auch öfters..
Aber für den WebService ist es sicher nicht schlecht. Schaun wir mal ob ichs umbaue


----------



## SebiB90 (24. Mrz 2009)

Also ich seh immer noch das Problem, das thE_29 auch erst gesehen hat.
Man muss dann halt den ApplikationContext immer durch geben und da seh ich kaum Sinn drin. Also Beispiel:

Ich erstelle alle meine Klassen, die was machen(also für BuinessLogic da sind), mit Spring. Diese Klassen brauche ich dann aber auch in den Models meiner GUI. Da hab ich dann wieder das Problem, wie kriege ich die da rein:

Singleton, das die Referezen auf die Objekte hat
Übergabe des ApplicationContext
DI
Da sowohl erstes ja nicht gewollt ist und zweites auch unschön ist, wird die 3 Variante genutzt und per DI die BuinessObjects in die Models gepackt. Aber dadurch müssen die Models ja auch per Spring erstellt werden. Da stellt sich jetzt wieder das gleiche Problem wie am Anfang nur diesmal mit den Models: Wie kriege ich die Models mit der View zusammen. Also habe ich wieder die 3 Möglichkeiten, aber die ersten beiden sind ja nicht gewünscht. Dann muss ich also auch die View mit Spring erzeugen usw usw. bis eigentlich die ganze Applikation nur über Spring erstellt wird. Kann das der Sinn sein?  irgendiwe sieht das für mich umständlich aus.


----------



## maki (24. Mrz 2009)

SebiB90,

auch wenn sich das jetzt schräg anhört, ein einziges Singleton ist ok 
Wird dann sozusagen als "ServiceLocator" für den SpringContext verwendet.

Martin Fowler hat dazu eigentlich schon alles beschrieben: Inversion of Control Containers and the Dependency Injection pattern

Das was DI anfangs schwierig macht, ist dass sich das Design der App dadurch ändert.
Das merkt man vor allem wenn man versucht DI in eine alte App zu integrieren welche mehrere Singletons verwendet.


----------



## Ebenius (24. Mrz 2009)

:shock: Mit Spring-Framework darf man also ein Anti-Pattern *einmal* verwenden? :lol:

Never mind, have had a clown for breakfast.


----------



## maki (24. Mrz 2009)

Ebenius hat gesagt.:


> :shock: Mit Spring-Framework darf man also ein Anti-Pattern *einmal* verwenden? :lol:


Aber aber, muss ich jetzt argumentieren dass das Singleton Pattern kein Antipattern ist sondern nur meist falsch eingesetzt wird?
*g*

Man muss das Singleton Pattern nicht verwenden mit Spring, aber bevor man die App komplett auf Spring umstellt, kann man auch Zwischenlösungen nehmen.


----------



## thE_29 (24. Mrz 2009)

Naja, die Frage ist ja auch, wie diese ganzen Frameworks drinnen aufgebaut sind!
Wer weiß ob die nicht auch oft solche SinglePattern´s haben 

Aber Google guice ist da wirklich einfacher zum confen! Ist zwar Java 1.5 only, dafür hat man keine XML Datei!


----------



## SebiB90 (24. Mrz 2009)

maki hat gesagt.:


> auch wenn sich das jetzt schräg anhört, ein einziges Singleton ist ok
> Wird dann sozusagen als "ServiceLocator" für den SpringContext verwendet.


Dieses vorgehen ist mir bekannt:


SebiB90 hat gesagt.:


> [...]kenn mich mit Spring noch kaum aus [...] Mein bisheriger Kontakt mit Spring beschränkt sich auf 3 Wochen Praktikum[...]Und in dem Projekt wurden mit Spring eigentlich nur die Remote-Beans in ein Singleton im Client reingepackt und über das Singleton wurde dann auf diese zugegriffen. [...]


Diese Singleton Klasse hieß auch ServiceLocator 
Da hier aber einige strikt gegen Singletons sind, würde ich gerne wissen, wie die mein Problem lösen würden.


----------



## Ebenius (24. Mrz 2009)

maki hat gesagt.:


> Aber aber, muss ich jetzt argumentieren dass das Singleton Pattern kein Antipattern ist sondern nur meist falsch eingesetzt wird?
> *g*


Nö. Das tu ich. Du hast Dich ja dagegen entschieden. *schmunzel*

Ebenius


----------



## maki (24. Mrz 2009)

SebiB90 hat gesagt.:


> Da hier aber einige strikt gegen Singletons sind, würde ich gerne wissen, wie die mein Problem lösen würden.


Vielleicht geht's nur mir so, aber ich verstehe deine Problembeschreibung nicht.



Ebenius hat gesagt.:


> Nö. Das tu ich. Du hast Dich ja dagegen entschieden. *schmunzel*


Ein Singleton sind keine Singleton*s* 8)


----------



## thE_29 (24. Mrz 2009)

So, hier mein Blog zu Google Guice!
http://www.java-forum.org/blogs/the_29/29-dependency-injuction-mit-google-guice.html

Hoffe das ist das gleiche wie bei TFA! Formatieren, Ergänzungen mache ich dann noch morgen oder heute am Abend.
Cool finde ich ja, dass er immer den richtigen Konstruktor findet  
Die Libs die man reinhängt sind einmal guice-1.0.jar mit 543KB und einmal aopalliance.jar mit 4.36KB. Also um einiges weniger als Spring + Logging Framework!


----------



## byte (24. Mrz 2009)

Wenns nur um DI geht, ist Guice sehr nett. Spring gibts halt schon seit 2003 und es ist immernoch recht XML-lastig, auch wenns sich seit Spring 2.5 stark verbessert hat. Dank Spring IDE (ein Spring Eclipse Plugin) lassen sich die XML-Dateien aber sehr komfortabel bearbeiten.

Für mich ist das Spring Framework aber nicht nur wegen DI die erste Wahl, sondern vor allem wegen dem perfekten JEE Support. Spring AOP, Spring Security, Spring Remote + das perfekte Zusammenspiel mit OR-Mappern macht Spring zur eierlegenden Wollmilchsau für meine derzeitigen Projektanforderungen.

Aber jedem das Seine.


----------



## SebiB90 (24. Mrz 2009)

Also, ich versuche es mal zu erklären.

also ich habe ein Klasse, die mir Kunden anlegt, bearbeiten und löschen kann (normal eigentlich nen Interface und dann ne Klasse die das implementiert, hier mal sofort als Klasse)
[HIGHLIGHT="Java"]public class KundenService {
  //die ganzen Methoden
}[/HIGHLIGHT]
Es gibt jetzt eine GUI die drauf zugreift, bzw genauer gesagt ein Model
[HIGHLIGHT="Java"]public class KundenModel {
   private KundenService kundenService = ServiceLocator.getInstance().getKundenService();
   //restliche Methoden
}[/HIGHLIGHT]
So würde ich den KundenService da rein holen ohne DI (ServiceLocator ist mein Singleton) und das Model könnte ich einfach im Controller erstellen und auch der View übergeben:
[HIGHLIGHT="Java"]public class KundenController {
  private KundenModel model;
  private KundenView view;
  public KundenController() {
    model = new KundenModel();
    view = new KundenView(model);
  }
}[/HIGHLIGHT]
So ist alles schön und gut, außer das Singleton 

Jetzt machen wir es mit DI. Der KundenService bleibt gleich, das erste was sich ändert wäre das KundenModel:
[HIGHLIGHT="Java"]public class KundenModel {
   @Autowire
   private KundenService kundenService;
   //restliche Methoden
}[/HIGHLIGHT]
So und jetzt habe ich folgendes Problem. Da es eine DI in KundenModel gibt, muss diese Klasse über den ApplicationContext(AC) von Spring erstellt werden. Und folgendes ist nicht mehr möglich:
[HIGHLIGHT="Java"]public class KundenController {
  private KundenModel model;
  private KundenView view;
  public KundenController() {
    model = new KundenModel(); // hier brauch ich die Instanz aus dem AC
    view = new KundenView(model);
  }
}[/HIGHLIGHT]
nur wie komme ich da jetzt dran? Durch den AC
[HIGHLIGHT="Java"]model = context.getBean("kundenModel");[/HIGHLIGHT]
doch den Context habe ich hier gar nicht(weil ich ihn nicht durchreichen will). Also wäre die andere möglichkeit wieder DI. Aber da taucht wieder ein Problem auf.
[HIGHLIGHT="Java"]public class KundenController {
  @Autowire
  private KundenModel model;
  private KundenView view;
  public KundenController() {
    view = new KundenView(model); // das model gibt es hier noch nicht
  }
}[/HIGHLIGHT]
also müsste ich auch KundeView im AC von Spring erstellen. Nur ich finde es irgendwie unschön, GUI in diesem zu erstellen. Aber gehen wir den Prozess mal weiter:
[HIGHLIGHT="Java"]public class KundenController {
  @Autowire
  private KundenModel model;
  @Autowire
  private KundenView view;
  public KundenController() {
  }
}[/HIGHLIGHT]
Also die View wird auch über den AC erstellt und das Model wird ihm auch über DI übergeben. 
Da es in KundenController wieder DIs gibt, muss ich ihn auch über den Spring AC erstellen. Damit andere auf diesen KundenController zugreifen können, müssen die wieder über den AC ran, der ja nicht in den Klassen vorhanden ist (ich will den nicht durchgeben, nur in der Main Methode haben). Also ist die einzige möglichkeit wieder über DI. Im besten Fall brauch in den KundenController nur noch in dem MainController meiner Applikation, im schlimmsten fall irgendwo in einer "tieferen" Klasse(MainController -> irgendeineKlasse -> damitNochBlöderWirdNochEIne -> KundenController ("->" soll heißen, dass die linke Klasse ne Referenz hat auf die rechte)), so dass ich noch mehrfach DIs brauche und es kann doch nicht sein, dass man mit Spring dann die ganze Applikation instanziert oder etwa doch? Zumindest bei der GUI scheint es mir unschön. Oder wie macht man es richtig?


----------



## byte (24. Mrz 2009)

SebiB90 hat gesagt.:


> ... und es kann doch nicht sein, dass man mit Spring dann die ganze Applikation instanziert oder etwa doch?


Doch.


----------



## KSG9|sebastian (25. Mrz 2009)

Das Singleton-Pattern an Sich ist ja nicht so übel. Dummerweise wird es meist zu Dingen mißbraucht für die es einfach nicht geeignet ist.

Die letzten Tage durfte ich zudem wieder leitvoll erfahren welche üblen Konstrukte und Reaktionen sich ergeben wenn Objekte statisch initialisiert werden und es mehrere Classloader gibt - wirklich niemandem zu empfehlen


----------



## thE_29 (25. Mrz 2009)

Was mir auch grad einfällt!
Ich würde das ganze gerne bei meiner WebApp nutzen.

Da ich ja irgendwo (static initializer oder so) die nur einmal instanzieren kann/muss, wie mache ich den das?

Weil der instanziert die Klassen ja von alleine. Ich müsste aber jetzt im Initializer den Kontext/Injector holen und dann diese Klassen/WebServices instanzieren. Wie soll das gehen?


----------



## Noctarius (25. Mrz 2009)

Du kannst nen Init-Servlet basteln oder das Ganze vom Spring / Guice realisieren (würd ich mal sagen)


----------



## thE_29 (25. Mrz 2009)

Naja, habe ein Spring + Xfire (was es ja nicht mehr gibt) Container/Servlet. Die Frage ist halt wo ich das einstellen muss...
Die Frage ist halt wer das macht...
Ich weiß das ich über die Annoatations @WebService... angebe, wie der Service heißt und ich definiere mit den Beans die Namen..


----------



## Noctarius (25. Mrz 2009)

Dann verstehe ich deine konkrete Frage gerade nicht *schäm* ^^


----------



## thE_29 (25. Mrz 2009)

Die Frage ist, wie ich den Init Servlet bastle


----------



## byte (25. Mrz 2009)

Noctarius hat gesagt.:


> Dann verstehe ich deine konkrete Frage gerade nicht *schäm* ^^



Verstehe auch nur Bahnhof. Geht mir aber häufig so bei Posts von thE_29.


----------



## Noctarius (25. Mrz 2009)

Hier ist ein kleines Lösungchen für dein Problemchen 

[highlight=xml]<!DOCTYPE web-app PUBLIC
 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
 "http://java.sun.com/dtd/web-app_2_3.dtd" >

<web-app>
	<servlet>
		<servlet-name>servlet-name</servlet-name>
		<servlet-class>my.project.servlets.InitServlet</servlet-class>
		<init-param>
			<param-name>param-name</param-name>
			<param-value>paramater value</param-value>
		</init-param>
		<load-on-startup>1</load-on-startup>
	</servlet>
</web-app>[/highlight]

[highlight=java]public class InitServlet extends HttpServlet {
	@Override
	public void init() {
		// Initialisierungen

		super.init();
	}

	@Override
	public void destroy() {
		// Aufräumarbeiten

		super.destroy();
	}
}[/highlight]


----------



## byte (25. Mrz 2009)

Wenns darum geht, Spring in Webapps zu benutzen, dann reicht ein kurzer Blick in die Doku: 3.8.5. Convenient ApplicationContext instantiation for web applications


----------



## SebiB90 (25. Mrz 2009)

byto hat gesagt.:


> Doch.


Was ne Antwort
Naja, irgendwie sträubt sich mein Kopf die GUI über Spring zu instanzieren. Ich finde es irgendwie merkwürdig =/ Aber wie gesagt, ich kenne mich mit Spring kaum aus. Ich werds vllt demnächst mal versuchen. Falls jemand ein bischen komplexeren Code (als in den Blogs) hat, in denen das der Fall ist, würde ich mich sehr über diesen freuen^^


----------



## byte (25. Mrz 2009)

Es liegt ja an Dir, bis zu welchem grad Du DI einsetzt. Spring hindert Dich nicht daran, nur bestimmte Objekte per DI zu erzeugen und andere Objekte proprietär per new Operator.

Ich habe z.B. in meinem momentanten Projekt Spring auch im Swing-Client im Einsatz. Mein MVC-Konzept sieht so aus, dass jede (komplexe) View innerhalb der GUI einen Controller hat, der die View verwaltet. Sowohl View als auch Controller erzeuge und initialisiere ich mit Spring DI. Die Modell-Objekte erzeugt Hibernate auf dem Server. Sie werden per Spring Remote an den Client übertragen.

Die View sind selbst JPanels und bestehen aus vielen JComponents. Die JComponents erzeuge ich in den Views _nicht _mit Spring. Stattdessen habe ich eine Factory geschrieben, die mir meine JComponents erzeugt.


----------



## SebiB90 (25. Mrz 2009)

Ok, ich werds mal ausprobieren 



byto hat gesagt.:


> Die View sind selbst JPanels und bestehen aus vielen JComponents. Die JComponents erzeuge ich in den Views _nicht _mit Spring. Stattdessen habe ich eine Factory geschrieben, die mir meine JComponents erzeugt.



Zum Verständnis: Die JComponents werden aber im Konstruktor der View oder in einer init Methode, die über Spring angerufen wird, erzeugt? Oder ruft das Programm dann noch irgendwo die init-Methode auf?


----------



## byte (25. Mrz 2009)

Es gibt init-Methoden, die von Spring aufgerufen werden. Die Konstruktoren sind leer.


----------



## thE_29 (25. Mrz 2009)

Müsste bei mir das hier sein:


```
<servlet>
    <display-name>XFire Servlet</display-name>
    <servlet-name>XFireServlet</servlet-name>
    <servlet-class>org.codehaus.xfire.spring.XFireSpringServlet</servlet-class>
  </servlet>
```

Problem ist, dass ich Spring 2.02 und XFire einsetze! Beides gibts in diesen Versionen nicht mehr und von XFire will ich nicht auf Apache CXF - Index CXF umsteigen, da ich nicht weiß ich da den MethodInterceptor reinhänge.. (damit ich die Methodenaufrufe loggen kann).
Leider ist das bei deren Umstiegsdoku nicht drinnen und ein Bekannter meinte mal das mit Axis2 man nicht mitdebuggen kann? Stimmt das oder geht das schon?


----------



## KSG9|sebastian (26. Mrz 2009)

So, zerfetzt mich weil ich sage 

*"Spring ist viel zu übermächtig und der leichtgewichtige Ansatz ist gar nicht so leichtgewichtig wie es immer gesagt wird"*

Ich wage sogar zu behaupten dass ich im Endeffekt besser dran bin wenn ich zwei oder drei kleine Frameworks verwende welche genau dem Zweck entsprechen, z.B. Google Guice. IMHO ist Spring einfach zu überfrachten mit Funktionalitäten..Spring IoC ist mittlerweile echt gut mit Annotations. Das enorm blöde dran ist aber dass ich nur mit Annotations nicht zum Ziel komme. Um die Anforderung zu erfüllen benötige ich zwingend wieder eine xml-Datei. Damit ist der ganze Ansatz für den Po.


----------



## tfa (26. Mrz 2009)

Wenn du sagst, "viel zu übermächtig"  musst du auch sagen wofür. Für kleine Minianwendungen? Einverstanden. Für alles was darüber hinaus geht ist Spring eine Überlegung wert. 

Außerdem besteht Spring selbst aus vielen Modulen. Es beihaltet also sozusagen viele kleine Frameworks unter einem Dach. Wenn Du nur DI brauchst, lässt du halt die uninteressanten Module weg. Fertig. 
Wenn man später doch andere Funktionalitäten braucht, linkt man halt das entsprechende Spring-Modul hinzu. Dann muss man sich nicht x verschiedene Frameworks auseinandersetzen.


----------



## byte (26. Mrz 2009)

Spring ist sehr mächtig, das ist richtig. Wenn ich nur DI machen wollen würde und noch keine Spring Kenntnisse hätte, dann würde ich mich wahrscheinlich auch gegen Spring entscheiden.

Um ehrlich zu sein ist DI für mich nicht mal der Hauptgrund, warum ich Spring benutze. Es sind die vielen wirklich sehr nützlichen Problemlösungen, die mir Spring bietet. Als da wären: 
- deklaratives Transaktionshandling für Hibernate
- deklarative Security für die Autorisierung
- deklaratives HTTP Remoting
- AOP
uvm.


----------



## guni (30. Mrz 2009)

Ursprünglich wollten wir in diesem Forum über den Sinn von Singletons im Allgemeinen diskutieren, oder?!
habe jetzt nicht die Zeit, das Ganze Forum durchzulesen und auch weit zu wenig Erfahrung, um mir eine eigene Überzeugung zum Thema Singletons zu bilden; möchte nur eine Frage in den Raum stellen, weil ich irgendwo im Einstiegspost so eine Behauptung in die Richtung "Wozu Singleton? Wenn ich ein Objekt nur einmal instanzieren muss, dann instanziere ich es eben nur einmal." gelesen habe. Wer sich zu dieser Einstellung bekennt, den möchte ich fragen:
Wieso gibt es in Java abstrakte Klassen? Wenn ich eine Klasse nicht instanzieren möchte, dann instanziere ich sie eben nicht?
Wieso gibt es in Java private Variablen? Wenn ich auf eine Variable nicht zugreifen soll, dann greife ich eben nicht darauf zu!
...
der Sinn dieses Patterns ist doch, dass ich mir oder anderen selbst eine Einschränkung setze um etwas zu verhindern, was nicht in mein Konzept passt, oder?!

mfg, guni


----------



## Noctarius (30. Mrz 2009)

Ansich richtig und ich benutze sie auch ab und an, aber der eigentliche Kritikpunkt ist halt in Java:

Du hast mehrere Classloader (bzw kannst mehrere haben) und du kannst nicht unterbinden, dass die Instanz mehrere Male erstellt wird, weil in Java 2 Klassen aus dem selben Bytecode durch 2 Classloader 2 verschiedene Klassen ergeben. Heißt es wird eine Instanz pro Classloader erstellt.


----------



## tfa (30. Mrz 2009)

> "Wozu Singleton? Wenn ich ein Objekt nur einmal instanzieren muss, dann instanziere ich es eben nur einmal."


Dieser Satz sollte nur dabei helfen zu erklären, was ein Singleton leisten soll. Wenn es in einer bestimmten Situation nur Grund für ein Objekt der Klasse X gibt, heißt das ja nicht, dass man aus X jetzt unbedingt ein Singleton sein muss. Vielleicht brauche ich morgen ein zweites X-Objekt. Von der Testbarkeit ganz zu schweigen. Deswegen soll man sich vor der Erschaffung eines Singletons erst fragen, brauch ich kjetzt wirklich nur ein Objekt, oder muss ich verhindern, dass es mehr als ein Objekt gibt?



> Wieso gibt es in Java abstrakte Klassen? Wenn ich eine Klasse nicht instanzieren möchte, dann instanziere ich sie eben nicht?
> Wieso gibt es in Java private Variablen? Wenn ich auf eine Variable nicht zugreifen soll, dann greife ich eben nicht darauf zu!


Weil man hierdurch anerkannte Prinzipien des OO-Entwurfs verletzt. Ebenso wie durch den unnötigen Gebrauch von Singletons.



Noctarius hat gesagt.:


> Ansich richtig und ich benutze sie auch ab und an, aber der eigentliche Kritikpunkt ist halt in Java:
> 
> Du hast mehrere Classloader (bzw kannst mehrere haben) und du kannst nicht unterbinden, dass die Instanz mehrere Male erstellt wird, weil in Java 2 Klassen aus dem selben Bytecode durch 2 Classloader 2 verschiedene Klassen ergeben. Heißt es wird eine Instanz pro Classloader erstellt.


Das ist bestimmt nicht der eigentliche Kritikpunkt, sondern eher Nebensache. Eine Gesetzteslücke, die selten auftritt. Ebensogut könnte man Diebstahl legalisieren, weil man ihn ja nicht 100%ig verhindern kann.


----------



## Noctarius (30. Mrz 2009)

[persönlicheMeinung]Wenn du dir hier die Posts durchließt ist es für 90% der Kritikpunkt schlechthin, 5% gehen auf Testbarkeit, 5% auf Sonstiges (so kam mir die Diskussion zu mindestens vor )[/persönlicheMeinung]


----------



## tfa (30. Mrz 2009)

Komische Wahrnehmung :bahnhof:


----------



## SlaterB (30. Mrz 2009)

> Vielleicht brauche ich morgen ein zweites X-Objekt. 

aber heute nicht, kann man dann doch umbauen..

> Von der Testbarkeit ganz zu schweigen. 

kann man dann doch umbauen..

> Deswegen soll man sich vor der Erschaffung eines Singletons erst fragen, brauch ich kjetzt wirklich nur ein Objekt, oder muss ich verhindern, dass es mehr als ein Objekt gibt?

muss ich verhindern, dass irgendjemand ein AbstractList-Objekt erzeugt? davon geht doch nix kaputt
muss ich verhindern, dass jemand direkt auf ein Attribut zugreift wenn dazu eigentlich der getter() da ist? selber schuld

das ganze ist eine übertriebene Groß-Projekt-Ansicht, die in jedes minimale Beispiel hineingedrückt wird,
vergleichbar:
in einem Konstruktor eines kleinen Test-JFrames steht setSize(400,400); + setVisible(true);

oh nein, was ist wenn man zwei verschiedene Fenster mit unterschiedlicher Größe erzeugen will oder ähnliches,
man kann es doch später anpassen..

kein Anfängerprogramm muss gegen x ClassLoader, Threadsicherheit, Testbarkeit, usw. abgesichert werden..


----------



## tfa (30. Mrz 2009)

Warum soll ich eine Zentralzeizung in mein neues Haus einbauen? Ist doch warm. Kann man später immer noch machen!
Warum soll ich eine Rentenversicherung abschließen? Gibt doch jeden Monat Geld. Kann man sich später drum kümmern.
Warum einen Regenschirm mitnehmen? Ich kann doch einen kaufen, wenn's anfängt zu regnen.



> übertriebene Groß-Projekt-Ansicht, die in jedes minimale Beispiel hineingedrückt wird ... Anfängerprogramm



Wer redet hier von minimalen Beispielen oder Anfängerprogrammen?


----------



## SlaterB (30. Mrz 2009)

das ist doch oft das Thema in diesem Forum und habe ich hier implizit angeführt,
also gerne etwas konkreter: angenommen man hat ein kleines Programm ohne gar den Begriff JUnit zu kennen..


----------



## tfa (30. Mrz 2009)

SlaterB hat gesagt.:


> angenommen man hat ein kleines Programm ohne gar den Begriff JUnit zu kennen..


... dann kann man machen, was man will, wenn's eh keinen interessiert. Oder man entwickelt sich weiter, wenn man später mal an mittelgroße oder große Programme gelassen werden will. Das soll jeder selbst entscheiden.


----------



## SlaterB (30. Mrz 2009)

über seinen Tonfall kann auch jeder selber entscheiden bzw. hoffentlich die, die das auch lesen..


----------



## Spacerat (30. Mrz 2009)

@tfa: Wenn ich also Singletons verwende, hab' ich kaum Chancen an einem Grossprojekt mit zu arbeiten? Kaum zu glauben... :lol:


----------



## maki (30. Mrz 2009)

Spacerat hat gesagt.:


> @tfa: Wenn ich also Singletons verwende, hab' ich kaum Chancen an einem Grossprojekt mit zu arbeiten? Kaum zu glauben... :lol:


Wirst lachen, aber genau das ist meist der Fall.
Das Problem in diesem Fall ist eben die Testbarkeit von mehreren Singletons.
Großprojekte ohne Tests gehen meist schief.


----------



## Emma82 (2. Jun 2009)

tfa hat gesagt.:


> ... dann kann man machen, was man will, wenn's eh keinen interessiert. Oder man entwickelt sich weiter, wenn man später mal an mittelgroße oder große Programme gelassen werden will. Das soll jeder selbst entscheiden.



Aber fängt man so nicht gewöhnlicherweise an?

Wenn jemand mit Java anfängt, dann nicht mit Java + Spring + JUnit + DesignPatterns + Modularer Aufbau + MVC ... schlichtweg unmöglich... ausser vielleicht man hat ein (fast) fertiges Großprojekt und ändert es in kleinen Teilen um sich nicht mit allem Gleichzeitig beschäftigen zu müssen.

Ich habe mal 4 SWS Java Vorlesungen gehabt, da war OOP Allgemein, UML 2 und HTML ebenfalls mit drin. Danach kann man es nicht, auch mit den zusätzlichen 2 SWS Übungen nicht.

Daher meine Meinung: Singletons sind genial (*zumindest* am Anfang), sie ersetzen das gesamte Spring/DI durch ein paar Zeilen Code-Muster. Viel Zeit sich um andere, meines Erachtens wichtigere Dinge zu kümmern... Richtiges JUnit Testing...

Beim Lesen bin ich da über Mock Objekte gestolpert (bisher unbekannt), ausserdem das man die Klassen alleine testet - habe ich eher selten gemacht, vorgehen bisher fange unten an und teste dich nach oben durch... sind unten keine Fehler, ist der Fehler weiter oben (unten in diesem Falle die Datenhaltung, oben die GUI oder der Einstiegspunkt)

Vielleicht vertrete ich mal die Meinung das Singletons vermieden werden sollten, aber niemals die Meinung das es Immer und in jedem Falle schlecht ist.


----------



## maki (2. Jun 2009)

> Daher meine Meinung: Singletons sind genial (zumindest am Anfang)


"Wenn man einen neuen Hammer hat, sieht jedes Problem wie ein Nagel aus"



> sie ersetzen das gesamte Spring/DI durch ein paar Zeilen Code-Muster


Eben nicht.
Das Design leidet meist, denn mit DI hat man ganz andere Möglichkeiten, Singletons sind meist fest "verdrahtet", Di eben nicht.



> Daher meine Meinung: Singletons sind genial (zumindest am Anfang), sie ersetzen das gesamte Spring/DI durch ein paar Zeilen Code-Muster. Viel Zeit sich um andere, meines Erachtens wichtigere Dinge zu kümmern... Richtiges JUnit Testing...


Das ist doch das Problem, dass sich Singletons nicht ersetzen lassen(oder nur sehr aufwändig) und schwer zu testen sind, sie *verhindern* oft richtiges Unittesting.


----------



## Noctarius (2. Jun 2009)

Emma82 hat gesagt.:


> Vielleicht vertrete ich mal die Meinung das Singletons vermieden werden sollten, aber niemals die Meinung das es Immer und in jedem Falle schlecht ist.



Genau das ist der Fall. Es gibt einige wenige Fälle wo ich auch auf ein Singleton zurückgreife auch wenn es sich trotzdem mit DI zu lösen wäre.

Gehen wir z.B. in einem Framework von einem globalen Eventmanager aus. Diesen würde ich IMMER als Singleton implementieren auch wenn es sich wunderbar über Dipendency Injection lösen ließ.


----------



## Wildcard (2. Jun 2009)

> Daher meine Meinung: Singletons sind genial (zumindest am Anfang), sie ersetzen das gesamte Spring/DI durch ein paar Zeilen Code-Muster.


Du kannst das Ding nicht Singleton nennen, wenn du es nicht als solches benutzt. Hauptkriterium muss dafür sein 'geht die Welt unter wenn jemand eine zweite Instanz erzeugt' 
Ist das nicht gegeben, dann ist es eben auch kein Entwurfsmuster mehr, sondern ein versteckt, statischer Zugriff. Wenn es ein versteckt, statischer Zugriff ist, musst du dir die Frage beantworten warum du den boilerplate Code schreibst anstatt direkt statische Methoden zu schreiben.
Wenn die Welt untergeht wenn eine zweite Instanz erzeugt wird, dann musst die dir genau überlegen welche Konsequenzen es bedeutet wenn die zweite Instanz dann doch da ist (was in Java schwierig ist).
Man kann oft auch mit Singletons guten Code schreiben, aber es ist meistens schwieriger als ohne.


----------



## Ensign (9. Jul 2009)

Eine statische Klasse mit statischen Membern tut es meist auch.


----------



## oopexpert (28. Aug 2011)

Ich sehe das Singleton in den meisten Fällen als semantisches Singleton und als Wurzelobjekt innerhalb einer Hierarchie von Verwaltungsobjekten. Wenn ich eine Buchhaltungssoftware schreibe, habe ich ein Singleton Buchhaltungssystem, wenn ich ein Software schreibe, die Bestellungen entgegennimmt habe ich ein Singleton BestellSystem.

Des Weiteren nutze ich Singletons für den zentralen Einstieg in Schichten. Remote-Schicht, Caching-Schicht, DAO-Schicht, Business-Schicht. Damit ist die Frage, wie man an eine Schicht herangeht für die darüberliegenden Schichten für alle Zeiten geklärt. Nur um eines klarzustellen: Es wird nicht ALLES über das Singleton erledigt, sondern es erfolgt nur der Einstieg in die Anwendung oder die Schicht. Das Singleton ist also keine God-Class, sondern dient als sauberer oberer Abschluss eines Moduls.


----------



## oopexpert (28. Aug 2011)

Ensign hat gesagt.:


> Eine statische Klasse mit statischen Membern tut es meist auch.



Das sind Utility-Klassen, aber keine Singletons.


----------



## Noctarius (28. Aug 2011)

Wenn man in die Verlegenheit kommt ein Singleton zu brauchen weiß man "Mein System ist groß genug für DI", nicht mehr und nicht weniger.


----------



## oopexpert (28. Aug 2011)

Noctarius hat gesagt.:


> Wenn man in die Verlegenheit kommt ein Singleton zu brauchen weiß man "Mein System ist groß genug für DI", nicht mehr und nicht weniger.



DI ist ein technisches Zugeständnis in großen Systemen, weil sich dies als praktikabel erwiesen hat. Es ist eine Aufweichung von OO, da die Semantik der Einzigartigkeit nicht als so wichtig angesehen wird, wie eine flexible Konfiguration.


----------



## Noctarius (28. Aug 2011)

Singelton ist keine OOP Abweichung... Achso.


----------



## maki (28. Aug 2011)

DI ist keine OO "Aufweichung", sondern nix anderes als implizite Abhängigkeiten zu expliziten umzugestalten, geht in Richtung Komponenten, also eine logische Fortführung der OOP.
Gof Singletons dagegen sind allzuoft globale Variablen 

Nachtrag: IMHO ist kein "System" zu klein für DI, genausoweing wie ich kein Projekt als zu klein für einen autom. Build erachte.


----------



## tfa (28. Aug 2011)

Noctarius hat gesagt.:


> Wenn man in die Verlegenheit kommt ein Singleton zu brauchen weiß man "Mein System ist groß genug für DI", nicht mehr und nicht weniger.



Der Spruch gefällt mir. :toll:


----------



## Noctarius (28. Aug 2011)

tfa hat gesagt.:


> Der Spruch gefällt mir. :toll:



Darfst du behalten


----------

