Ich habe kürzlich Java-Code geerbt und muss ihn in ein Projekt integrieren, an dem ich gerade arbeite. Mein Projekt ist ein Service-Agent, der XML-Nachrichten verarbeitet und transformiert. Beim Durchsuchen des neuen Codes habe ich die folgende Protokollierungsklasse entdeckt:
%Vor%Diese Klasse umschließt im Prinzip log4j mit (einem anderen) Singleton. Die gesamte Protokollierung der Klassen, die ich integrieren muss, sieht ungefähr so aus:
%Vor%Ich sehe keinen offensichtlichen Vorteil für die Verwendung einer zusätzlichen Klasse für die Protokollierung. Daher überlege ich, diesen Code zu refactorisieren, um die MyLogger-Klasse zu entfernen und sich wie folgt anzumelden:
%Vor%Dies würde den Protokollierungsmechanismus über das gesamte Projekt hinweg konsistent machen. Bevor ich das tue, würde ich gerne wissen, ob es Vorteile gibt, Log4j mit einer Singleton-Klasse zu verpacken, die ich vielleicht vermisse. Vielen Dank!
BEARBEITEN: Vielen Dank für die hilfreichen Antworten - ich erhalte von jedem neue Einsichten. Akzeptiert Nathan Hughes 'Antwort für das Aufzeigen verlorener Funktionalität, indem die Klasse intakt gelassen wurde - ich hatte angenommen, dass der größte Nachteil darin bestand, den Singleton in Ruhe zu lassen, einfach Code-Bloat war. Ich werde die Klasse zerstören.
Befreien Sie sich davon. Die Verwendung dieser Monstrosität bedeutet, dass alle Logging-Vorgänge, die sie durchlaufen, mit demselben Logger (MyLogger) und derselben Methode aufgelistet werden (weshalb die Argumente für ihre Methoden die Klasse der Sache enthalten, die protokolliert wird). Das bedeutet nicht nur, dass Sie jedem Loggeraufruf Klassen-, Methoden- und Zeilennummerninformationen hinzufügen müssen. Sie können Logfiles für verschiedene Pakete nicht so filtern, wie Sie den typischen Log4j-Ansatz mit Klassen als Logger verwenden könnten .
Dieses Ding ist ein Stück Müll und du bist besser dran ohne es.
Der einzige Vorteil, den ich sehen könnte, ist, dass es einfach wäre, die log4j-Implementierung durch eine andere Logging-Implementierung zu ersetzen, oder die Logging-Funktion etwas viel individueller zu gestalten, wie zum Beispiel in eine Ihrer eigenen Datenbanken zu loggen.
>Das heißt, ich würde den Code immer noch refaktorieren, um log4j direkt zu verwenden. Oder, in meinem Fall, eher SLF4J .
Eine Sache, die Ihr geerbter Code tut, ist, dass log4j nichts threadsicher macht. Da in getInstance() keine Sperre vorhanden ist, können Sie potenziell mehr als eine Instanz verteilen und die Singleton-Absichten des Codes aufheben.
Sie verlieren auch die Möglichkeit, Protokollierungsstufen für jede Klasse festzulegen, je nachdem, was Sie tun.
Der einzige Fehler, den ich feststellen kann, ist wegen dieser Erklärung:
%Vor% Der Logger ist im Wesentlichen an das Objekt MyLogger angehängt und alle Logging-Informationen / Fehler / Warnungen usw. werden mit MyLogger "verlinkt". Sie haben keine Ahnung, welches Objekt die Protokollierungsinformationen hinzugefügt hat, keines.
Der einzige Vorteil, den ich mit diesem Singleton sehe, ist:
static final Logger -Implementierung deklarieren. Ich habe das auch in meiner Firma gesehen, aber ich empfehle diese Art von Setup nicht. Verwenden Sie lieber SLF4J oder das Java Logging Framework.