ロギングに適した設計パターンはどれですか？
プログラム内のいくつかのイベントをログに記録する必要がありますが、プログラムの実際の機能についてではないため、ログコードをプログラムの外部に保持する方が適切です。それで、コードから完全に除外し、オブザーバーとリスナーのみを使用してイベントをログに記録する必要があるかどうかを教えてもらえますか？または、何かをログに記録する必要がある場合はいつでも、次のようなコード行を追加できます。
MyGloriousLogger.getXXXLogger().Log(LogPlace, new LogObject(z1, z2, z3, z4, ..., z99));
オブザーバーデザインパターンを使用するのは間違いですか？別のデザインパターンが必要ですか？または私はデザインパターンについて考えるのをやめるべきですか？
PS1。リスナーとオブザーバーのみを使用してログを記録する場合は、プログラムのオブザーバーとリスナーを追加して改善する必要があります。
PS2。 Javaにログインするためのさまざまなライブラリがあり、Java.utils.loggingを使用していることは確かですが、特別なオブジェクトをログに記録するためのラッパーが必要です。
Aspect Oriented Programming を使用します。これは、メソッドに関するAfter、Before、Aroundのアドバイスを使用します。そこで、必要に応じて、APIの開始前、後、または特定の条件でログを追加し、メインコードをログコードから分離できます。
まあ、オブザーバーは私には不向きに聞こえます。また、ロガー呼び出しを「必要な場所に」投げると、コードが破壊され、SRPに違反します。
たとえば、このためにAOPに興味があるかもしれません。そのため、メソッドアノテーションを介してロガー呼び出しをアタッチできます。
出力が複数の場所に到達する可能性がある場合、責任の連鎖は良いパターンのようです。 UMLには、コンソール、errorFile、および3番目の単純な情報ロガーを対象とする別のロガーがあります。
通常、logLevelsは異なりますが、ロギングファイルは同じです。
オブザーバーパターンは、ロギングコードをアプリケーションコードから切り離しているため、ロギングに適しているとは言えません。これは良い方法です。別のロギングメカニズムへの移行はこの方法で簡単です。ログを記録するたびにイベントを発生させ、適切なリスナーがイベントを受信してログに記録します。すべてのレジスタのリストを保持する中間のシングルトンオブジェクトが必要です。
このようにして、ロギングコードをアプリケーションコードから分離できることがわかります。