Frage

Ich füge einen CVS-Zweig zusammen und eine der größeren Änderungen ist die Ersetzung eines Singleton-Musters an jedem Ort, an dem es auftritt, durch abstrakte Klassen, die einen statischen Initialisierungsblock und alle statischen Methoden haben.

Lohnt es sich, dies beizubehalten, da viele Konflikte zusammengeführt werden müssen? In welcher Situation würde sich diese Umgestaltung lohnen?

Wir betreiben diese App unter Weblogic 8.1 (also JDK 1.4.2)


Entschuldigung Thomas, lass es mich klarstellen.

Die HEAD-Version hat das traditionelle Singleton-Muster (privater Konstruktor, getInstance() usw.)

Die Verzweigungsversion hat keinen Konstruktor, ist eine „öffentliche abstrakte Klasse“ und hat alle Methoden des Objekts so geändert, dass sie „statisch“ sind.Der Code, der früher im privaten Konstruktor vorhanden war, wird in einen statischen Block verschoben.

Dann werden alle Verwendungen der Klasse geändert, was zu mehreren Konflikten bei der Zusammenführung führt.

Es gibt einige Fälle, in denen diese Änderung vorgenommen wurde.

War es hilfreich?

Lösung

Unter dem Gesichtspunkt der reinen Laufzeitleistung ist der Unterschied wirklich vernachlässigbar.Der Hauptunterschied zwischen den beiden liegt darin, dass der „statische“ Lebenszyklus mit dem Klassenlader verknüpft ist, während es sich beim Singleton um einen regulären Instanzlebenszyklus handelt.Normalerweise ist es besser, sich vom ClassLoader-Geschäft fernzuhalten. Dadurch vermeiden Sie einige knifflige Probleme, insbesondere wenn Sie versuchen, die Webanwendung neu zu laden.

Andere Tipps

Ich würde einen Singleton verwenden, wenn er einen beliebigen Zustand speichern müsste, andernfalls statische Klassen.Es macht keinen Sinn, etwas zu instanziieren, nicht einmal eine einzelne Instanz, es sei denn, es muss etwas gespeichert werden.

Statisch ist schlecht für die Erweiterbarkeit, da statische Methoden und Felder nicht durch Unterklassen erweitert oder überschrieben werden können.

Es ist auch schlecht für Unit-Tests.Innerhalb eines Unit-Tests können Sie nicht verhindern, dass die Nebenwirkungen verschiedener Tests übergreifen, da Sie den Klassenlader nicht steuern können.Statische Felder, die in einem Unit-Test initialisiert wurden, sind in einem anderen sichtbar, oder schlimmer noch, die gleichzeitige Ausführung von Tests führt zu unvorhersehbaren Ergebnissen.

Singleton ist im Allgemeinen ein gutes Muster, wenn es sparsam verwendet wird.Ich bevorzuge die Verwendung eines DI-Frameworks und lasse dieses meine Instanzen für mich verwalten (möglicherweise in verschiedenen Bereichen, wie in Guice).

Wenn mein ursprünglicher Beitrag das richtige Verständnis hatte und die Diskussion von Sun, auf die verlinkt wurde, korrekt ist (was meiner Meinung nach der Fall sein könnte), dann muss man meiner Meinung nach einen Kompromiss zwischen Klarheit und Leistung eingehen.

Stellen Sie sich diese Fragen:

  1. Macht das Singleton-Objekt klarer, was ich tue?
  2. Benötige ich für diese Aufgabe ein Objekt oder eignet es sich eher für statische Methoden?
  3. Benötige ich die Leistung, die ich durch den Verzicht auf einen Singleton erzielen kann?

Meiner Erfahrung nach ist das Einzige, was zählt, welches in Unit-Tests einfacher zu simulieren ist.Ich hatte immer das Gefühl, dass es einfacher und natürlicher ist, Singleton nachzuahmen.Wenn Ihre Organisation die Verwendung von JMockit zulässt, spielt das keine Rolle, da Sie diese Bedenken ausräumen können.

Hilft diese Diskussion?(Ich weiß nicht, ob es tabu ist, auf ein anderes Programmierforum zu verlinken, aber ich möchte lieber nicht nur die gesamte Diskussion zitieren =) )

Sun Diskussion zu diesem Thema

Das Urteil scheint zu lauten, dass es in den meisten Fällen keinen großen Unterschied macht, obwohl die statischen Methoden technisch gesehen effizienter sind.

Schreiben Sie Code, um die Leistung zu messen.Die Antwort hängt von der JVM ab (das JDK von Sun funktioniert möglicherweise anders als JRockit) und den VM-Flags, die Ihre Anwendung verwendet.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top