Ein zentrales Objekt in vielen anderen Klassen nutzen?

[krx]

Hallo,

ich habe eine Klasse, die zentrale Funktionen bereitstellt und viele andere Klassen, die diese nutzen sollen. Meine Frage ist: Wie greife ich von den "vielen anderen Klassen" auf die "Klasse mit den zentralen Funktionen" zu? Wenn ich davon ausgehe, dass von Letzterer immer ein Objekt namens "zentral" besteht, kann ich trotzdem nicht einfach in den "vielen anderen Klassen" zentral.methode() aufrufen, da das Objekt nicht erreicht werden kann.

Danke

 

[faetzminator]

Für solche Sachen verwendet man ein Dependency Injection Framework wie z.B. Spring MVC. Wenn du allerdings sagst, dass du "zentrale Funktionen" in einer Klasse hast, dann hast du das Konzept von OOP ggf. noch nicht verstanden.

 

[Camino]

Und was spricht dagegen, die Methoden static zu machen, und dann mit Zentral.methode() aufzurufen?

 

[krx]

Es geht um einen Logger und einen E-Mail-Versender (mit verschiedenen vorgefertigten Mails und Empfängern) und die soll es eben nur ein mal geben. Das sind ja keine spezifische Funktion einer bestimmten Klasse. Gibt es für diese Sonderfälle vielleicht noch einen gebräuchlichen Ansatz?

static ist so eine Sache. Die Methoden der Zentralklasse sollen trotzdem gewisse Variablen haben, die sie dynamisch zur Laufzeit zugewiesen bekommen, die dann aber über die gesamte Laufzeit konstant sind (z.B. der Log-Pfad). Und bei statischen Methoden müsste ich diese Variablen ja bei jeder Nutzung der Methode immer wieder mitgeben, was mir auch unsinnig erscheint.

 

[faetzminator]

Camino, static ist in 99% der Fälle ein fail.

[...] Logger [...]

Verwende log4j o.ä. und machs dann so wie mans macht:

private static final Logger LOGGER = LoggerFactory.getLogger(MyClass.class);[/quote]

[quote="krx, post: 985283"][...] E-Mail-Versender [...][/QUOTE]
Das klingt ganz nach DI.

 

[krx]

private static final Logger LOGGER = LoggerFactory.getLogger(MyClass.class);

Wenn ich das richtig sehe, muss ich das in jeder Klasse, die den Logger verwenden soll, als Attribut definieren. Nur hat dann wiederum jedes Objekt seinen eigenen Logger, den ich jedes mal neu konfigurieren muss (Log-Pfad usw.), oder?

 

[ARadauer]

Nur hat dann wiederum jedes Objekt seinen eigenen Logger, den ich jedes mal neu konfigurieren muss (Log-Pfad usw.), oder?

nö das wird zentrall ein einer Konfig Datei konfiguriert..

Ob jetzt DI die Lösung für jede kleine Anwendung ist bezweifle ich aber auch...

 

[krx]

static ist in 99% der Fälle ein fail.

Warum?

Und was ich nicht verstehe: man kann die Einstellungen des Loggers im Programm selbst über bestimmte Methoden ändern, z.B. Logger.setLoggingLevel(). Allerdings wurde ja vorher kein Objekt von Logger erzeugt. Wo werden denn dann die Einstellungen hingespeichert? Ich wollte auch gerade eine Klasse schreiben, die eine statische Methode hat, welche ein bestimmtes Attribute des Objektes ausgibt. Allerdings kann ich "this" nicht in statischen Methoden benutzen. Wie kann der Logger dann Attribute setzen?

 

[Marco13]

Verwende ein Singleton. Das ist wahnsinnig praktisch.

:joke:

Im Ernst, speziell für Logger gibt es da SEHR ausgefeilte Mechanismen. Mit den Details kenne ich mich im Einzelnen nicht sooo gut aus, aber im speziellen ist es z.B. in bezug auf die Konfiguration so, dass z.B. ein Logger für "com.somepackge.other.TheClass" die Einstellungen vom "Parent-Logger" erben kann, d.h. vom logger für das package "com.somepackge". Im speziellen könnte bei dir dann im Pseudocode sowas vorkommen wie

getLogger("com.somepackge").setLevel(INFO);
getLogger("com.somepackge").setOutput(System.out);
getLogger("com.somepackge").setFormat(someFormat);

// Feinerer Level für die Klasse "Mail", aber sonstige Einstellungen wie oben
getLogger("com.somepackge.Mail").setLevel(TRACE);

Für den allgemeinen Fall kann diese Frage aber schwieriger zu lösen sein (in Logging-Frameworks wurde viel Hirnschmalz gesteckt, um diesen Fall zu behandeln, und es ist ja nur ein sehr spezieller Anwendungsfall)

 

[Stefan0001]

vielleicht würde schon ein einfaches singleton pattern reichen...

mfg

 

[JohannisderKaeufer]

Den E-Mail Versender statisch zu machen (static oder Singleton) klingt auf den ersten Blick verlockend.
Die Probleme entstehen allerdings sobald man versucht, das ganze zu testen.
Erst recht, wenn man automatisiert testen möchte.

Mit static bekommt man es hin, dass fürs Testen andere E-Mail Konten und Server verwendet werden in dem andere Configurationsdateien bereitgestellt werden.
Um zu testen ob der Email Versand auch tatsächlich geklappt hat, muß man dann allerdings auch eine gewisse Zeit warten um dann nachzusehen ob im E-Mailprogramm tatsächlich die gewünschte Mail vorhanden ist. Sehr unpraktisch!

Jetzt könnte man auf den Gedanken kommen und im Mailservice eine Weiche einbauen, die bei Tests keine Mails versendet, sondern einfach anzeigt, welche Mails verschickt werden sollten (vgl. Mock). Das klappt zwar, hat aber den immensen Nachteil, daß nun Test-Code im Programm vorhanden ist, der im Produktivbetrieb nicht gebraucht wird. Unschön!

DI ist eine Lösung. Der MailService erhält ein Interface und die Klassen, die den MailService benötigen, bekommen einen MailService im Konstruktor übergeben oder per DI-Framework injiziert. Zum Testen erstellt man sich einen Mock, der ebenfalls das MailService Interface implementiert, aber keine Mails verschickt. Dieser wird dann zum Testen anstelle eines richtigen MailService übergeben.

 

[krx]

Ich denke, dass ich die ganze Sache erstmal mit einem Singleton bewerkstelligen werde. Habe das eben mal ausprobiert und es funktioniert wie gedacht/gewünscht. Mit den Einschränkungen beim Testen kann ich leben. Wenn dann doch noch Zeit bleibt, ist die Umstellung auf DI (hoffentlich) schnell vollzogen.

Eine Verständnisfrage stellt sich mir aber: wenn ich in zwei verschiedenen Klassen zwei verschiedene Singleton-Objekte erstelle - mySingleton1 in Example1.class und mySingleton2 in Example2.class - dann wirken sich die Änderung an mySingleton1 auch auf mySingleton 2 aus. Das ist zwar auch so von mir gewünscht und ja auch Sinn und Zweck von Singletons, allerdings kann ich nicht nachvollziehen, warum das funktioniert. Existiert das Singleton auch nur ein mal im Speicher, egal in wie vielen Klassen ich es aufrufe? Wenn ja, wie geht das? Ich habe dieses Muster verwendet: Singleton (Entwurfsmuster) ? Wikipedia (oberes Beispiel ohne Holder)

 

[Marco13]

Hinter meinem Hinweis mit dem Singleton war ein " :joke: " - nur um das nochmal zu betonen....

 

[krx]

Ah, ok. Habe ich nicht so gewertet. Dann sollte ich mich wohl doch noch mal in DI einlesen, zu mal Wikipedia auch sagt, dass das Singleton fast schon zu den Anti Patterns gezählt wird.
Die Frage ist nur, ob sich das für meinen Fall lohnt (eher kleines Programm). Ich müsste erstmal schauen, wie man so ein Framework einbindet, wie man damit arbeitet usw...

 

[Marco13]

Zugegeben, ich verwende auch gelegentlich static (bei irgendwelchen Registries oder Einstellungen) wo es aus objektiver "Software-Nachhaltigkeits"-Sicht ein no-go ist: Für irgendeine kleine Demo oder ein Utility mal eben ein DI-Framework einbinden erscheint leicht als overkill (obwohl sowas wie Google Guice schon recht kompakt und übersichtlich aussieht).

Relevant wäre da vielleicht auch die Frage, wie nachhaltig das sein soll. Muss man damit rechnen, dass es da Unit-Tests dazu geben wird und das, was du jetzt machst, in 3 Jahren immernoch drin ist? Und DANN die paar Stunden Zeit, die du heute mit einen einfachen 'static' sparen könntest, vielleicht mehrere Monate Nachbesserungsaufwand verursacht und jemanden zur Verzweiflung bringt?

 

[tfa]

Man braucht nicht unbedingt ein DI-Framework um DI benutzen zu können. Das funktioniert auch "von Hand", z.B. durch Setter oder Übergabe der benötigten Objekte im Konstruktor. Bei sehr kleinen Projekten ist das auch kein großer Aufwand.

 

[krx]

Habe mich jetzt mal in das Thema DI eingelesen. Ist, denke ich, verständlich und sollte für mein Programm hoffentlich auch ohne weiteres implementierbar sein. Oder gibt es da eventuelle Fallstricke?

Warum gibt es DI-Frameworks? Die Abhängigkeiten muss ich ja so oder so definieren und der Aufwand erscheint mir mit einem Framework nicht viel geringer. Aber ich denke bestimmt einfach in zu kleinen Dimensionen.

 

[JohannisderKaeufer]

DI-Frameworks zeigen ihren Nutzen erst richtig, wenn man mehrere Abhängigkeiten injiziert oder die Abhängigkeiten erst sehr tief in einem Objektgraphen benötigt werden.

Z.B. eine Datenbankverbindung (DS) um bei einem Buttonklick eine Abfrage durchzuführen.

Diese müsste man ohne Framework an ein JFrame übergeben. Dieses würde die DS an ein JPanel weiterreichen und dieses dann schließlich an einen ActionListener übergeben, der damit dann erst arbeitet.


Ein weiterer Vorteil ergibt sich, wenn man verschiedene Configurationen nutzt. Z.B. für den Produktivbetrieb, die Entwicklung, das Testen. Oder eine Deluxeversion und eine Freeversion.

Die Änderungen, werden dann nur in den Configurationsdateien gemacht.

 

[krx]

Mir ist jetzt auch erst bewusst gewesen, dass man die Objekte, Variablen usw. die eine Klasse benötigt, ihr immer mitgeben muss, wenn man nicht statisch arbeiten will. Und wenn es eine Hierarchie der Objekterzeugung gibt und erst das unterste Objekt der Hierarchie ein bestimmtes anderes Objekt aus einer höheren Hierarchieebene braucht, müssen die Objekte weiter oben in der Hierarchie das benötige Objekt immer weiter und weiter geben, damit es schlussendlich ganz unten in der Hierarchie verfügbar ist (ich glaube, dass JohannisderKaeufer darauf raus wollte). Das ist irgendwie blöd, weil dieses "Weitergeben" so eine künstliche Funktion von Klassen ist, die sie eigentlich nicht brauchen.

Oder sehe ich da was falsch?

 

[ThreadPool]

[...]weiter oben in der Hierarchie das benötige Objekt immer weiter und weiter geben, damit es schlussendlich ganz unten in der Hierarchie verfügbar ist (ich glaube, dass JohannisderKaeufer darauf raus wollte). [...]

Das ändert sich mit DI aber auch nicht. Es bleibt die Frage wer übernimmt wo die "Verdrahtung" der expliziten Abhängigkeiten. Das kannst du per Hand über Factories, Builders und wie sie nicht alle heißen machen oder über so ein Framework wie z.B. Guice.

Und das mit dem Singleton ist nicht so das Problem des Singletons sondern der Verwendung als "implizite Abhängigkeit", d.h. du verwendest es einfach irgendwo im Code anstelle es als z.B. über den Konstruktor oder Setter als "explizite Abhängigkeit" reinzureichen.

Wenn du es dennoch als "implizite Abhängigkeit" verwenden möchtest gibts da noch eine kleine Variation die eine Mischung aus Singleton und Factory ist. Wie das dann aussieht wenn z.B. die Implementation über den hauseigenen ServiceLoader organisiert wird findest du hier Injectable Singleton - APIDesign.

 

[krx]

Wenn ich per DI einem Objekt ein anderes Objekt injiziere, das als Attribut benötigt wird, dann wird ja nur die Referenz auf das zu injizierende Objekt übergeben. Entsprechend kann man das injizierte Objekt ja jederzeit von außen ändern, selbst wenn es private ist, oder?

 

[Olli_M]

Ah, ok. Habe ich nicht so gewertet. Dann sollte ich mich wohl doch noch mal in DI einlesen, zu mal Wikipedia auch sagt, dass das Singleton fast schon zu den Anti Patterns gezählt wird. Die Frage ist nur, ob sich das für meinen Fall lohnt (eher kleines Programm). Ich müsste erstmal schauen, wie man so ein Framework einbindet, wie man damit arbeitet usw...

Ich bin von Singletons auch nicht mehr so angetan wie früher. Ich hatte mal einen ätzenden Fehler produziert, indem ich in einem Singleton ein NumberFormat-Objekt drinhatte, das ich global und vor allem in verschiedenen Threads einsetzte. Da NumberFormat aber nicht threadsafe ist, bekam ich falsche Formatierungen, zudem noch sporadisch und unreproduzierbar. Ist natürlich kein Problem des Singletons an sich, aber solche Sachen können als Begleiterscheinungen des Singletons auftreten, und sind kaum vernünftig testbar.

Olli

 

[faetzminator]

Wenn ich per DI einem Objekt ein anderes Objekt injiziere, das als Attribut benötigt wird, dann wird ja nur die Referenz auf das zu injizierende Objekt übergeben. Entsprechend kann man das injizierte Objekt ja jederzeit von außen ändern, selbst wenn es private ist, oder?

Ja, wenn das Objekt nicht immutable ist - wie z.B. String. Ist aber bei einem Singleton ebenfalls der Fall. Je nach DI-Framework hast du Scopes (ich kenn Spring MVC), mit welchen du steuern kannst, wann welche Beans/Dependencies neu erstellt werden.