Wie erstellt man ein Paket für die Verwendung eines Loggers, abhängig vom Programm "Caller" in Golang?

Question

Wie ich sehen kann, hat jeder Entwickler seinen eigenen Bedarf und Ansatz, um die gleichen Dinge/Bedürfnisse zu lösen. Als Beispiel, Protokollierung. Es gibt viele Logging-Pakete, die auf unterschiedliche Weise funktionieren und jeder Entwickler wählt den, der am besten zu seinen Bedürfnissen/Präferenzen passt. Denke daran, ich möchte ein Paket erstellen, das das Logging-Paket des Aufrufers verwenden soll. Ist es möglich? Jemand hat eine Möglichkeit, das zu tun?

Etwas wie folgt aus:

Hauptcode Logrus Paket:

package main 

import (
    "os" 

    "github.com/Sirupsen/logrus" 

    "gitlab.com/tutume/_testing/globallogs/mypack" 
) 

var Log = logrus.New() 

var myPack pack.Pack 

func main() { 
    isDebug := os.Getenv("MYAPP_LOGLEVEL") 
    switch isDebug { 
    case "Debug": 
     Log.Level = logrus.DebugLevel 
    case "Info": 
     Log.Level = logrus.InfoLevel 
    default: 
     Log.Level = logrus.ErrorLevel 
    } 
    Log.Formatter = &logrus.TextFormatter{ 
     ForceColors: true, 
    } 

    Log.Debug("Debugging...") 
    Log.Info("Informing...") 
    Log.Error("Normal...") 

    myPack.Logger = Log 
    myPack.DoSomething() 

} 

mypack Code:

package pack 

type Pack struct { 
    Logger interface{} 
} 

func (mp *Pack) DoSomething() { 
    // Logger.Debug("Debugging...") 
    // Logger.Info("Informing...") 
    // Logger.Error("Normal...") 
} 

Answer 1

Wenn ich verstehe, was Sie versuchen, zu tun, müssen Sie festlegen, eine Schnittstelle, die ein Protokollierungspaket implementieren würde. Wenn Sie Logger als leere Schnittstelle definieren, können Sie keine dieser Methoden aufrufen. Stattdessen müssen Sie eine Schnittstelle definieren, die die Methoden enthält, die Sie verwenden möchten (Debug, Info, Fehler usw.). Jedes Protokollierungspaket müsste dann diese Methoden implementieren. Wenn ein bestimmtes Protokollierungspaket nicht über die richtigen Methoden verfügt, müssten Sie einen Wrapper-Code schreiben, um die Schnittstelle so zu implementieren, wie Sie sie definiert haben.

Answer 2

Ich suchte und fand this post. Sehr interessant. Als Infrastrukturmanager/-techniker habe ich von vielen Software, die ich verwende (und verwendet habe), immer die Möglichkeit, so tiefgründigere Informationen wie möglich zu finden, um Probleme zu identifizieren und zu beheben, Sicherheitsvorschlag. Viele Male sehen wir uns mit einigen Problemen konfrontiert, dass wir selbst im Debug-Modus nicht in der Lage sind, die genaue Ursache des Problems zu finden, sondern nur die "wahrscheinliche" Ursache gefunden haben. Wenn ich jetzt zurück in die Entwicklungswelt gehe und sehe, wie Entwickler mit Logs und Bibliotheken arbeiten, denke ich, dass dies ein Grund sein könnte (der Mangel an "Interoperabilität zwischen den Hauptprogrammen und seinen Bibliotheken). Da Bibliotheken normalerweise" ihre eigenen haben "Logging (oder überhaupt nicht Logging) und viele Male, gibt keine" vollständige Kontrolle "über das, was in der Bibliothek passiert, in den meisten Fällen wird der Entwickler, der das Hauptprogramm entwickelt (unter Verwendung solcher Bibliotheken), nicht in der Lage sein Ich verstehe natürlich, dass Sie in der Open Source-Welt, wenn Sie detailliertere Informationen haben möchten, einschließlich der von Ihnen verwendeten Bibliotheken, da es Open Source ist, Ihre Änderungen einfach vornehmen können und dann ist es getan, aber dann könnte dies die Verwendung einer Bibliothek (die den Vorteil hat, Bibliotheken zu benutzen, um nicht Zeit zu verlieren, um das Rad neu zu erstellen, in anderer Welt Wiederverwendbarkeit) nicht so hilfreich sein, wie es sein sollte Als die referenzierte Post, eine Möglichkeit, damit umzugehen, ist, immer die notwendigen Informationen an den Anrufer zu senden. Aber normalerweise funktioniert es für Fehler, Fatals und vielleicht Info-Level-Events. Aber für Debug und Trace zum Beispiel ist es bei der Entwicklung von Bibliotheken (aus vielen Gründen) nicht "praktisch", und dann denke ich, dass ein großer Grund ist, dass ein Entwickler, wenn er eine Bibliothek entwickelt, bereits alle Debugs und Traces benötigt zum Testen, aber nicht unbedingt zurück zum Anrufer. Ein anderer Weg, der in der Post beschrieben wird, ist die Verwendung von Handlern, aber dadurch wird der Entwickler der Bibliothek viel mehr zu tun haben. Wie Andy geantwortet hat (und auch in der Post besprochen wird), besteht eine Alternative darin, eine Schnittstelle zu erstellen, die den Programmlogger des Hauptprogramms empfängt und verwendet, und damit diese Option ordnungsgemäß funktioniert, sollte das stdlib-Protokoll (oder eine Protokollierungsbibliothek) verwendet werden implementieren Sie die meisten Protokollierungsstufen) für den Fall, dass das aufrufende Programm die Protokollierung nicht berücksichtigt. Für meine "Wünsche" gerade jetzt (wie ich bin in Programmieren wieder und beginne in Go), werde ich einen "hässlichen Code" erstellen, um meine Bedürfnisse zu erfüllen und weiter zu lernen und Wege zu versuchen, das "perfekte Logging System" zu erreichen Inzwischen benutzt IMHO Schnittstellen wie Andy vorgeschlagen hat.