Opfern C++ - Logging-Frameworks die Wiederverwendbarkeit?

Question

In C++ gibt es kein De-facto-Standardprotokollierungswerkzeug. Meiner Erfahrung nach rollen Läden ihre eigenen. Dies verursacht jedoch ein gewisses Problem, wenn wiederverwendbare Softwarekomponenten erstellt werden sollen. Wenn alles in Ihrem System von der Protokollierungskomponente abhängt, macht dies die Software weniger wiederverwendbar, was im Grunde alle nachgeschalteten Projekte dazu zwingt, Ihr Protokollierungs-Framework zusammen mit den Komponenten zu verwenden, die sie wirklich wollen.

IOC (Abhängigkeitsinjektion) hilft nicht wirklich mit dem Problem, da Ihre Komponenten von einer Protokollierungsabstraktion abhängen müssten. Das Protokollieren von Komponenten selbst kann Abhängigkeiten von Datei-E/A, Auslösemechanismen und anderen möglicherweise unerwünschten Abhängigkeiten hinzufügen.

Wird durch die Hinzufügung einer Abhängigkeit zu Ihrem proprietären Protokollierungsrahmen die Wiederverwendbarkeit der Komponente beeinträchtigt?

Answer 1

Ja. Aber die Abhängigkeitsinjektion wird in diesem Fall helfen.

Sie können eine abstrakte Protokollierungsbasisklasse erstellen und Implementierungen für die Protokollierungsframeworks erstellen, die Sie verwenden möchten. Ihre Komponenten sind nur von der abstrakten Basisklasse abhängig. Und Sie injizieren die Implementierungen zusammen mit allen Abhängigkeiten nach Bedarf.

Answer 2

Ja, Mendelt hat Recht. Genau das machen wir in unseren Produkten. Alles hängt von der ILogger-abstrakten Schnittstelle ab, aber es hängt von nichts anderem ab. In der Regel wird eine ausführbare Datei oder eine High-Level-DLL erstellt, um eine tatsächlich implementierte Logger-Schnittstelle zu erstellen und zu injizieren.

Answer 3

Wenn Sie Bibliotheken erstellen möchten, die nicht neu kompiliert werden, aber eine Protokollierungsschnittstelle bereitstellen möchten, ist es vielleicht eine gute Möglichkeit, dem Benutzer (der Bibliothek) einen Rückruf zu ermöglichen.

Beim Initialisieren der Protokollierung mit Ihrer Bibliothek müssen sie den Rückruf festlegen, und dann ist der Klebecode für sie zuständig, damit sie mit allem, was sie haben, gut spielt.

Wenn Sie die Signatur des Callbacks wie eine Standardfunktion aussehen lassen können, die ihnen immer zur Verfügung steht, bietet sie ihnen eine einfache Standardoption, wenn sie keinen Logger haben.

Zusätzlich könnte der Aufrufer Komponenten aus der Bibliothek mehrfach instanziiert haben, und für Konflikte mit Ressourcenkonflikten oder Threadproblemen einen anderen Logger-Callback für jeden bereitstellen.