Singletons sind...

[thE_29]

Die Frage ist, wie ich den Init Servlet bastle

 

[byte]

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]

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]

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]

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]

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]

Ok, ich werds mal ausprobieren

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]

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

 

[thE_29]

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]

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]

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]

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]

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]

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]

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

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]

[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]

Komische Wahrnehmung :bahnhof:

 

[SlaterB]

> 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]

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]

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]

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]

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

 

[Spacerat]

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

 

[maki]

@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]

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

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]

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]

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]

Eine statische Klasse mit statischen Membern tut es meist auch.

 

[oopexpert]

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]

Eine statische Klasse mit statischen Membern tut es meist auch.

Das sind Utility-Klassen, aber keine Singletons.

 

[Noctarius]

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]

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]

Singelton ist keine OOP Abweichung... Achso.

 

[maki]

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]

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]

Der Spruch gefällt mir. :toll:

Darfst du behalten