C++ ロギング フレームワークは再利用性を犠牲にしますか?

Question

C++ には、事実上の標準のログ ツールはありません。私の経験では、お店は独自の判断をします。ただし、再利用可能なソフトウェア コンポーネントを作成しようとすると、少し問題が発生します。システム内のすべてがロギング コンポーネントに依存している場合、ソフトウェアの再利用性が低くなり、基本的に、下流のプロジェクトが本当に必要なコンポーネントとともにロギング フレームワークを使用することになります。

コンポーネントはロギング抽象化に依存する必要があるため、IOC (依存性注入) は問題の解決にはあまり役に立ちません。ロギング コンポーネント自体が、ファイル I/O、トリガー メカニズム、およびその他の望ましくない依存関係への依存関係を追加する可能性があります。

独自のロギング フレームワークに依存関係を追加すると、コンポーネントの再利用性が犠牲になりますか?

Answer 1

はい。ただし、この場合には依存性注入が役に立ちます。

抽象ロギング基本クラスを作成し、使用するロギング フレームワークの実装を作成できます。コンポーネントは抽象基本クラスにのみ依存します。そして、必要に応じて、実装とその依存関係をすべて注入します。

Answer 2

はい、メンデルトは正しいです。私たちはまさにこれを製品で実現しています。すべては ILogger 抽象インターフェイスに依存しますが、他のものには依存しません。通常、実行可能ファイルまたは高レベル DLL は、実際に実装された Logger インターフェイスを構築し、それを挿入します。

Answer 3

再コンパイルされないライブラリを構築しようとしているが、ロギング インターフェイスを提供したい場合は、(ライブラリの) ユーザーがコールバックを提供できるようにするのが良い方法かもしれません。

ライブラリを使用してロギングを初期化する際、コールバックを指定する必要があります。その後、グルー コードは、ライブラリが持っているものとうまく連携できるようにするために必要です。

コールバックの署名を常に利用できる標準関数のように見せることができれば、実際にロガーを持っていない場合でも、簡単なデフォルト オプションが提供されます。

さらに、呼び出し元はライブラリからコンポーネントを複数回インスタンス化しており、リソース競合やスレッドの問題のために、それぞれに異なるロガー コールバックを提供したい場合があります。