私は現在、中規模から大規模のJavaコードベースでロギングメカニズムをアップグレードすることを検討しています。メッセージは現在、Debugクラスの静的メソッドを使用してログに記録されます。これからSLF4Jやcommons-loggingなどに切り替えることをお勧めします。
アプリケーションアーキテクトは、SLF4Jへの依存関係をカプセル化することを好みます（おそらく、前述のDebugクラスにラップすることによって）。これにより、将来、ロギングの実装を簡単に変更できるようになります。
SLF4Jはすでに具体的なロギングの実装を抽象化しているため、これは私にはやり過ぎのように思えます。
SLF4Jのようなサードパーティのロギング抽象化を別の自家製の抽象化でラップする価値はありますか？
私はあなたに完全に同意します：ラッパーのラッパーのラッパーは手に負えなくなっています。アーキテクトは、特にSLF4Jが他のロギングシステムを簡単にラップできることを理解していないのではないかと思います。そのため、「実装の変更」は、ラップページをもう1つ追加しなくても完全に実行可能です。
アーキテクトがラッパー (つまり SLF4J) をラップしたいという欲求の背後にある動機は、アプリケーションを SLF4J から分離することだと思います。明らかに、アプリケーション内から SLF4J API を呼び出すと、SLF4J への依存関係が作成されます。ただし、以下で説明するように、分離の原則を繰り返し適用することも同様に正当です。リチャード・ドーキンスの質問を思い出します: 神が宇宙を創造したのなら、誰が神を創造したのですか?
実際、SLF4J をラップするラッパーに分離原則を適用することもできます。SLF4J-wrapper が何らかの形で SLF4J より劣っている場合、分離の原因は役に立たないでしょう。可能ではありますが、ラッパーがオリジナルと同等またはそれを超えることはかなりまれです。SWT は注目に値する反例として挙げることができます。ただし、SWT はかなりのコストがかかる大規模なプロジェクトです。さらに言えば、定義上、SLF4J ラッパーは SLF4J に依存しています。同じ一般的な API を持つ必要があります。将来、大幅に異なる新しいロギング API が登場した場合、ラッパーを使用するコードを新しい API に移行することは、SLF4J を直接使用するコードと同様に困難になります。したがって、ラッパーはコードの将来性を保証するものではなく、追加の間接化を追加してコードを重くする可能性があります。
要するに、他にやるべきことがなかったとしても、ラッパーの付加価値はほぼゼロであることが保証されているため、SLF4J のラッピングに時間を無駄にするべきではありません。
このトピックは、SLF4J FAQ エントリでも紹介されています。
私はそれを包むことを好みますが、述べられた理由のためではありません。別のフレームワークと交換する機能が問題になる場合は、java.util.loggingまたはSLF（java.util.loggingはラッパーほど簡単には使用できませんが、非常に実行可能です）を使用して、交換してください。（さらに別の）ラッパーを使用する理由は、適切なロギング方法をコードで体系化するためです。一般に、アプリケーションは、すべてのシステムエラーに例外が伴うなどのサブセットを必要とするか、標準のログレベルをいつ使用するかについての特定のガイダンスを持っています。これらの決定は、いくつかのメソッドにカプセル化して、大規模なコードベースでより一貫性のあるロギング決定を作成できます。
ただし、実装を交換できるようにすることが動機である場合は、車輪の再発明を行わないでください。SLFは仕事に最適です。それを使用するだけです。
これには1つの例外があります。コードが多くの可能なアプリサーバーに展開されることを意図している場合は、ログの選択が、フレームワークが使用しているものの潜在的に古いバージョンまたは新しいバージョンと競合するリスクがないことを確認する必要があります。
アーキテクチャの宇宙飛行士に、slf4j はすでに log4j などの他のロギング実装のラッパーとして機能できることを説明してください。したがって、将来、他のロガーを使用する必要があり、slf4j 用のアダプターがない場合は、必要に応じてそれを作成できますが、他のロガーをラップするだけのロギング フレームワーク全体を作成する代わりに、単にアダプターになります。そのためのフレームワークを設計し、独自のアダプターを作成する必要があります。
すべてのラッパーの問題は、実際にラップする方法と提供する機能の決定です。
現在の Debug クラスはわかりませんが、かなり基本的なものだと思います。
おそらく次のような機能はありません
Debug クラスが非常に基本的なものである場合、これは実際には非常に便利です:)
これは、グローバル検索 & デストロ... エラー... 置換を実行することで、SLF4J に切り替えることができる可能性が高いことを意味します。
ただし、バックアップを作成してください... ;)
また、新しいプロジェクトでは log4j の代わりに logback を使用する必要がありますか?も参照してください。、Java でのログ記録はどうなっていますか? 、どの log4j ファサードを選択するか? 、Java ロギング フレームワークのシーンで方法を見つけます。java.util.loggingで十分ですか? . (ネタバレ: java.util.logging を使用しないでください。かなりお願いします)
将来、ロギングフレームワークを切り替えることを検討している場合は、ロガーを切り替えることができるレイヤーを追加する価値があるかもしれません。そうでなければ、彼らがあなたがおそらく必要とするであろうすべてを提供するなら（もちろんあなたの水晶玉を使って）、そのフレームワークに強く依存することはおそらく大丈夫です。
現在の設定で柔軟性を変更できる場合は、ラッパーは必要ありません。