ロギングに適した設計パターンはどれですか？

プログラム内のいくつかのイベントをログに記録する必要がありますが、プログラムの実際の機能に関するものではないため、ログコードをプログラムの外部に置いた方がよいでしょう。それで、コードから完全に除外し、オブザーバーとリスナーのみを使用してイベントをログに記録する必要があるかどうかを教えてもらえますか？または、何かをログに記録する必要がある場合はいつでも、次のようなコード行を追加できます。

MyGloriousLogger.getXXXLogger().Log(LogPlace, new LogObject(z1, z2, z3, z4, ..., z99));

Observer設計パターンを使用するのは間違いですか？別のデザインパターンが必要ですか？または私はデザインパターンについて考えるのをやめるべきですか？

PS1。リスナーとオブザーバーのみを使用してログを記録したい場合は、プログラムのオブザーバーとリスナーを追加して改善する必要があります。

PS2。Javaにログインするためのさまざまなライブラリがあり、java.utils.loggingを使用していることは確かですが、特別なオブジェクトをログに記録するためのラッパーが必要です。

Logging通常、責任の連鎖パターンで実装されます。もちろん、それをFacadeと組み合わせることができます（私もそうします）。私は実際には自分でリスナーやオブザーバーを使用しません。

メソッドの前後、前後のアドバイスを使用するアスペクト指向プログラミングを使用します。そこで、必要に応じて、APIの開始前、後、または特定の条件でログを追加し、メインコードをログコードから分離できます。

まあ、オブザーバーは私には不向きに聞こえます。また、ロガー呼び出しを「必要な場所に」投げると、コードが破壊され、SRPに違反します。

たとえば、このためにAOPに興味があるかもしれないので、メソッドアノテーションを介してロガー呼び出しをアタッチできます。

出力が複数の場所に到達する可能性がある場合、責任の連鎖は良いパターンのようです。UMLには、コンソール、errorFile、および3番目の単純な情報ロガーを対象とする別のロガーがあります。

通常、logLevelsは異なりますが、ロギングファイルは同じです。

ロギングコードがアプリケーションコードから切り離されているため、オブザーバーパターンはロギングに適しているとは言えません。これは良い方法です。別のロギングメカニズムへの移行はこの方法で簡単です。ログを記録するたびにイベントを発生させ、適切なリスナーがイベントを受信して​​ログに記録します。すべてのレジスタのリストを保持する中間のシングルトンオブジェクトが必要です。

このようにして、ロギングコードをアプリケーションコードから分離できることがわかります。