Mein Problem betrifft die Protokollierung von Bibliotheksklassen (Klassen, die in Bibliotheken verwendet werden),
Wir verwenden derzeit log4cxx , aber die log4j Bibliothek implementiert dieselben Konzepte.
Angenommen, ich habe einen Prozess mit mehreren Entitäten, A, B und C. Jeder von ihnen verwendet viele verschiedene Klassen und Funktionen, die im Code klar getrennt sind.
A, B und C verwenden viele Bibliotheksklassen, Funktionen, Objekte, Ressourcen und manchmal sogar globale Variablen (Legacy-Code, nichts, was ich dagegen tun kann ...) - nennen wir sie alle foo
Die Protokollierung von A, B und C stellte sich als ein Leistungsproblem heraus , das Protokoll wird gesprengt, wenn wir die Protokollierungsstufe auf debug setzen. Nach dem Betrachten unseres Systems kamen wir zu diesen Schlussfolgerungen:
foo zum Protokollieren gedruckt werden, müssen wir sehen, welches Objekt es heißt, A, B oder C. foo gibt, möchten wir die Debug-Ebene für jedes foo getrennt ändern können
foo sollte als eine gemeinsame Bibliothek behandelt werden, es kann nicht direkt von A, B oder C abhängen. foo verwenden (zum Beispiel wird die gleiche Instanz unserer Ressourcenbehandlungsklasse verwendet A, B und C), im Protokoll möchten wir sehen, welche Klasse verwendet foo . Das ist, was wir bis jetzt gefunden haben -
A, B und C haben separate Logger. Eine globale Variable (die in einer anderen Bibliothek mit allen Protokollierungshelfern und Wrappern gespeichert ist) behält immer die aktuelle Protokollberichterstattung bei. Jedes Mal, wenn eine Entität mit ihrer Logik beginnt, setzt sie die globale Variable auf den richtigen Logger. Wenn ein foo dem Protokoll Bericht erstatten möchte, meldet es sich über die globale Variable und fügt den Namen (und den Kontext) der Protokollnachricht hinzu.
Das Problem ist, dass es sich anfühlt, als müsste es etwas geben, das das schon tut, die Lösung fühlt sich nicht sauber an und hält eine globale Variable wie diese ...
Machen wir hier etwas falsch? Gibt es dafür eine bessere Lösung?
Ich kenne keine bestehende Lösung. Ich würde wahrscheinlich mit einem Logger mit einer Schnittstelle wie folgt kommen (ob es eine Standalone-Implementierung oder nur ein Wrapper auf Ihrem bestehenden ist):
%Vor%Die Hauptabweichung von allgemeinen Protokollbibliotheken ist der kontextsensitive Modulfilter. Wir haben vielleicht Setups wie die folgenden, um verschiedene Ebenen einzustellen, je nachdem, wer den Aufruf (den Kontext) macht:
%Vor%Dann wird der Anruffluss wie folgt aussehen:
%Vor%Nicht sicher, ob solch eine Schnittstelle Ihren Zweck erfüllt. Wie auch immer, ich betrachte Interface immer zuerst als einen guten Ansatz. Sobald Sie eine übersichtliche Oberfläche haben, sollte die Implementierung einfach sein.
Wenn die separate Bibliothek selbst eine Klasse ist, können Sie eine Variable auf Klassenebene in der Bibliothek verwenden, um die Loggerinstanzreferenz zu halten. Ich programmiere nicht oft in C ++ oder Java, aber ich denke, dass eine Variable auf Klassenebene in C ++ und Java "statisch" ist.
Es ist immer noch eine globale Variable darunter, aber zumindest ist es eine klassenspezifische globale Variable (wie eine Klassenvariable namens debugLog.log , wobei debugLog der Klassenname ist).