Singletons sind...

Singletons sind..

  • ein Antipattern. Ich benutze sie überhaupt nicht.

    Stimmen: 7 7,4%

  • manchmal ein nützliches Entwurfsmuster. Ich setzte sie hin und wieder ein.

    Stimmen: 72 76,6%

  • total praktisch. Ich verwende sie oft und gerne.

    Stimmen: 15 16,0%
  • Anzahl der Umfrageteilnehmer
    94
Status
Nicht offen für weitere Antworten.
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.
 
>> 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 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..
Zum Vergrößern anklicken....
UnitTests testen eben Einheiten. Das bedeutet, der Testgegenstand sollte weitestgehend von seiner Umgebung isoliert getestet werden können.

Ebenius
 
thE_29 hat gesagt.:
Meinst du sowas hier mit GoF Singletons? Archive Hive Blog Archive GoF: Singleton
Zum Vergrößern anklicken....
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..
Zum Vergrößern anklicken....
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 😉
 
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.
 
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
 
thE_29 hat gesagt.:
Jo, aber warum werden diese Einheiten nicht funktionieren?
Zum Vergrößern anklicken....
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.
Zum Vergrößern anklicken....
Greifst du auf auf das Singleton zu oder die Klasse die du testest?

Versuche dein Singleton mal durch ein Mockobjekt auszutauschen 😉
 
Zuletzt bearbeitet von einem Moderator:
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.
 
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 😉
 
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 😉
Zum Vergrößern anklicken....

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.
 
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!

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 😉
Zum Vergrößern anklicken....
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 😉
 
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 😀
 
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.
 
Ok, dann mache ich das in ein paar Jahren wenn ich mal Zeit habe mich durch Dokus durchzuwühlen..
 
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.
 
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:
 
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?
 
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 😀
 
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 😀
Zum Vergrößern anklicken....
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
 
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*
 
Zuletzt bearbeitet:
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!
 
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.
 
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?
Zum Vergrößern anklicken....

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).
 
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 🙂
 
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:
  1. Singleton, das die Referezen auf die Objekte hat
  2. Übergabe des ApplicationContext
  3. 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.
 
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.
 
:shock: Mit Spring-Framework darf man also ein Anti-Pattern einmal verwenden? :lol:

Never mind, have had a clown for breakfast.
 
Ebenius hat gesagt.:
:shock: Mit Spring-Framework darf man also ein Anti-Pattern einmal verwenden? :lol:
Zum Vergrößern anklicken....
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.
 
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!
 
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.
Zum Vergrößern anklicken....
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. [...]
Zum Vergrößern anklicken....
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.
 
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!
 
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. 😉
 
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?
 
Zuletzt bearbeitet:
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 😉
 
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?
 
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..
 
Status
Nicht offen für weitere Antworten.

Aktuelle Jobs

Neue Themen

Ähnliche Themen

problem mit singletons
Antworten: 14
Singletons und Multithreading
Antworten: 11
threadsicherheit bei singletons
Antworten: 6
Was Units für Pascal sind, sind ? für Java
Antworten: 9
Strings sind ungleich obwohl sie in der Ausgabe gleich sind
Antworten: 10

Zurück
Oben