Singleton zum Lesen von properties-Datei in eine Java-webapp; richtige Ansatz?
Meine spaghetti-monster verbraucht XML aus verschiedenen SOAP-Dienste, und die URL für jedes service ist hardcoded in der Anwendung. Ich bin in den Prozess der Zerstörung dieser hardcoding, und die Speicherung der URLs in eine properties-Datei.
In Bezug auf das Lesen der Datei mit den Eigenschaften, die ich möchte zu umfassen, die Logik in einem Singleton referenziert werden können, wie gebraucht.
Ändern:
accountLookupURL ="http://prodServer:8080/accountLookupService";
Zu diesem:
accountLookupURL =urlLister.getURL("accountLookup");
Singleton wäre, die in den urlLister.
Ich habe eher scheuen das Singleton-Muster, nur weil ich habe nicht, es zu benutzen, zuvor. Bin ich auf dem richtigen Weg, hier?
Dank!
IVR-Avenger
Du musst angemeldet sein, um einen Kommentar abzugeben.
Haben Sie nicht gesagt, warum Sie brauchen nur eines, was immer es ist, die werden immer die URL. Wenn das nur beinhaltet das Lesen einer properties-Datei, ich glaube nicht, dass Sie brauchen nur ein. Mir scheint, dass zwei threads Lesen die gleichen Eigenschaften, die Datei zur gleichen Zeit ist nicht ein problem überhaupt.
Es sei denn, Sie denken, dass einige Objekt, das nur liest die properties-Datei einmal und dann werden die Inhalte für die zukünftige Verwendung. Aber dies ist eine web-Anwendung, mit der rechten? Also die Art und Weise zu begegnen, Lesen Sie in den Eigenschaften, wenn die Anwendung startet, und speichern Sie in der Anwendung Kontext. Es gibt nur einen Anwendungskontext, so ist Ihre "einzige" Objekt.
Als alternative, haben Sie verwenden Sie so etwas wie Apache Commons Configuration (oder vielleicht ein anderes Konfigurations-framework)?
Singletons sind geeignet für dieses Szenario, ABER Sie haben zu stellen Sie sicher, Sie tun das singleton-Recht.
So, zum Beispiel, was Bozhno schlägt ist kein singleton ist, es ist eine hässliche Mischung aus fiesen Statik nicht mockable, nicht leicht prüfbar, nicht injizierbaren, und in der Regel kommt zurück zu beißen Sie in den Arsch.
Einem akzeptablen singleton ist nur eine Durchschnittliche Klasse mit einer bemerkenswerten Ausnahme, dass gewährleistet ist, entweder durch sich selbst oder durch äußere Fabrik/framework (e.g Spring IoC) existieren in nur einer Instanz. Wenn Sie gehen mit dem ersten Ansatz, sowas
Das ist akzeptabel, wenn Sie nicht wirklich das Gefühl, die Notwendigkeit für eine Fabrik, anders, und nicht mit jedem IoC-container in Ihrer app (gute Idee, denken über die Verwendung einer wenn). Beachten Sie den Unterschied von Bozhno Beispiel: das ist eine gute Vanille-Klasse, wo nur statisch eine Instanz var und eine Methode, um es zurückzugeben. Beachten Sie auch die synchronized-Schlüsselwort erforderlich für die lazy-Initialisierung.
update: Pascal empfiehlt diese sehr coolen post über einen besseren Weg, um lazy-init singletons in die Kommentare unten: http://crazybob.org/2007/01/lazy-loading-singletons.html
Basierend auf Ihre Vorschläge, und die Tatsache, dass ich nicht glaube, ich habe so viel Zugriff auf diese Anwendung, wie ich gehofft hatte (eine Menge, es ist abstrahiert in kompilierter code), hier ist die Lösung, die ich habe, gekocht. Dies ist, natürlich, ein stub und ausgestaltet werden muss mit besseres exception-handling und ähnliches.
Ist dies eine gute Leistung als meine "erste" Singleton?
Dank,
IVR-Avenger
Dennoch nochmals darauf hinweisen, das offensichtliche, Singleton verwendet werden, wenn alle client-code sollte sprechen auf eine einzige Instanz der Klasse. Also, verwenden Sie eine Singleton-IFF Sie sicher, dass Sie würde nicht wollen, laden mehrere properties-Dateien auf einmal. Ich persönlich möchte in der Lage sein, die Funktionalität (laden mehrere properties-Dateien).
Singletons sind veränderlich Statik und daher böse. (Vorausgesetzt, eine halbwegs brauchbare definition von "singleton".
Code, der verwendet die statische (transitive Beziehung), hat Annahmen über so ziemlich alles andere (in diesem Fall ein web-server und dem internet). Veränderlich Statik schlechtes design und schlechtes design lässt viele Aspekte go rotten (Abhängigkeit, Verständlichkeit, testing, Sicherheit, etc).
Als ein Beispiel, das einzige, was anhalten späten Versionen von JUnit 3 verwendet wird, in einem Sandkasten laden einer Konfigurations-Datei in einem static initialiser. Bei Parametrierung von Oben, hätte es kein Problem.