language-agnostic - OOP コンテキストでの適切なロギング

Question

私が最初にオブジェクト指向プログラミングを学び始めて以来、私が苦労してきた問題があります: 「適切な」OOP コードでロガーを実装するにはどうすればよいでしょうか?

これは、コード内の他のすべてのオブジェクトがアクセスできるようにするメソッドを持つオブジェクトを意味します。このメソッドは、ログに使用するコンソール/ファイル/その他に出力します。したがって、このオブジェクトはロガーオブジェクトになります。

ロガーオブジェクトをグローバル変数として設定したくありません。なぜなら、グローバル変数は良くないからです。しかし、すべてのオブジェクトで呼び出すすべてのメソッドのパラメーターで logger オブジェクトを渡す必要もありません。

大学時代、このことを教授に持ち込んだとき、彼は実際には答えてくれませんでした。この機能を実装する可能性のあるパッケージ (Java など) が実際に存在することを認識しています。しかし、私が最終的に探しているのは、これを適切かつ OOP の方法で自分で実装する方法の知識です。

score 13 · Accepted Answer

You do want to establish the logger as a global variable, because global variables are not bad. At least, they aren't inherently bad. A logger is a great example of the proper use of a globally accessible object. Read about the Singleton design pattern if you want more information.

score 4 · Accepted Answer

非常によく考えられた解決策がいくつかあります。OO をバイパスし、別のメカニズム (AOP) を使用するものもあります。

ロギングは、実際には OO にはあまり適していません (これは問題ありませんが、すべてがそうであるわけではありません)。自分で実装する必要がある場合は、各クラスの先頭で「ログ」をインスタンス化することをお勧めします。

プライベート最終ログ=新しいログ(これ);

すべてのロギング呼び出しは簡単です: log.print("Hey");

これにより、シングルトンよりもはるかに使いやすくなります。

ロガーに渡したクラスを認識させ、それを使用してログに注釈を付けます。log のインスタンスがあるため、次のようなことができます。

log.addTag("ビル");

また、ログは各エントリにタグビルを追加できるため、表示のフィルタリングを改善できます。

ただし、log4j とチェーンソーは、すぐに使える完璧なソリューションです。単に学術的ではない場合は、それらを使用してください。

score 2 · Accepted Answer

グローバルにアクセス可能なロガーは、テストが面倒です。「集中型」ロギング機能が必要な場合は、プログラムの起動時に作成し、ロギングが必要なクラス/メソッドに挿入します。次のようなものを使用するメソッドをどのようにテストしますか。

public class MyLogger 
{
    public static void Log(String Message) {}
}

どのようにモックに置き換えますか？

より良い：

public interface ILog 
{
    void Log(String message);
}

public class MyLog : ILog 
{
    public void Log(String message) {}
}

score 1 · Accepted Answer

私は常にシングルトンパターンを使用してログオブジェクトを実装してきました。

score 0 · Accepted Answer

おそらく、透過的な方法でロギングを挿入することは、アスペクト指向プログラミングのイディオムに属するでしょう。しかし、ここではオブジェクト指向デザインについて話しています...

私の意見では、シングルトンパターンが最も役立つ可能性があります。LoggingServiceクラスのパブリックな静的メソッドを介して、任意のコンテキストからLoggingサービスにアクセスできます。

これはグローバル変数によく似ているように見えるかもしれませんが、そうではありません。シングルトンクラス内に適切にカプセル化されており、すべての人がアクセスできるわけではありません。これにより、実行時でもロギングの処理方法を変更できますが、ロギングの動作を「vilain」コードから保護します。

私が取り組んでいるシステムでは、さまざまなサブシステムからのメッセージを区別できるようにするために、いくつかのロギング「シングルトン」を作成します。これらは実行時にオン/オフを切り替えることができ、フィルターを定義することができ、ファイルへの書き込みが可能です...あなたはそれに名前を付けます。

score 0 · Accepted Answer

私は過去に、ロギングにアクセスする必要のあるクラスの基本クラス（または言語がサポートしている場合はインターフェース）にロギングクラスのインスタンスを追加することでこれを解決しました。何かをログに記録すると、ロガーは現在の呼び出しスタックを調べ、そこから呼び出し元のコードを判別し、ログステートメントに関する適切なメタデータ（ソースメソッド、利用可能な場合はコード行、ログに記録されたクラスなど）を設定します。多くのクラスにはロガーがあり、ロガーは自動的に決定できるメタデータで特別に構成する必要はありません。

これはかなりのオーバーヘッドを追加するので、本番ロギングには必ずしも賢明な選択ではありませんが、そのように設計すると、ロガーの側面を条件付きで無効にすることができます。

現実的には、私はほとんどの場合コモンズロギングを使用します（私はJavaで多くの作業を行います）が、上記で説明した設計には有益な側面があります。他の誰かがすでにデバッグにかなりの時間を費やしている堅牢なロギングシステムを持つことの利点は、よりクリーンな設計と見なすことができるものの必要性を上回りました（特にこの投稿の詳細が不足していることを考えると、これは明らかに主観的です）。

静的ロガーでpermgenメモリの問題が発生する問題が発生したため（少なくとも、それが問題だと思います）、おそらくすぐにロガーを再検討する予定です。

score 0 · Accepted Answer

私は log4* と一緒に AOP に賛成です。これは本当に助かりました。たとえば、Googleはこの記事をくれました。そのテーマについてさらに検索を試みることができます。

score 0 · Accepted Answer

0

シングルトンパターンを見ることができます。

于 2008-09-17T19:24:47.343 に答える

score 0 · Accepted Answer

ロガーをシングルトンクラスとして作成し、静的メソッドを使用してアクセスします。

score 0 · Accepted Answer

もう 1 つの考えられる解決策は、ロギング/ストアドプロシージャをカプセル化する Log クラスを使用することです。new Log();そうすれば、シングルトンを使用しなくても、必要なときにインスタンス化できます。

データベース経由でログを記録している場合、注入する必要がある唯一の依存関係はデータベースであるため、これが私の推奨するソリューションです。ファイルを潜在的に使用している場合、依存関係を注入する必要はありません。グローバルまたは静的ロギングクラス/関数を完全に回避することもできます。

score 0 · Accepted Answer

（IMHO）「ロギング」がどのように行われるかは、ソリューション設計の一部ではなく、Java のシステムやカレンダーなど、たまたま実行している環境の一部です。

あなたの「良い」ソリューションは、特定のロギング実装に可能な限り疎結合されているものであるため、インターフェースを考えてください。Sun がどのようにそれに取り組んだかの例については、こちらのトレイルをチェックしてください。おそらく、Sun は非常に優れた設計を考え出し、学習できるようにすべてをレイアウトしました!

score 0 · Accepted Answer

静的クラスを使用すると、オーバーヘッドが最小になり、単純なアセンブリ参照内のすべてのプロジェクトタイプからアクセスできます。

シングルトンは同等ですが、不要な割り当てが含まれることに注意してください

複数のアプリドメインを使用している場合は、メインドメイン以外のドメインから静的クラスにアクセスするためにプロキシオブジェクトが必要になる場合があることに注意してください。

また、複数のスレッドがある場合は、出力のインターレースを避けるためにログ機能をロックする必要がある場合があります

IMHO ロギングだけでは不十分なので、CALMと書きました

幸運を！

score 0 · Accepted Answer

グローバル変数を避けるために、グローバル REGISTRY を作成し、そこにグローバルを登録することを提案します。

ロギングについては、シングルトンクラスまたはロギング用の静的メソッドを提供するクラスを提供することを好みます。

実際には、既存のロギングフレームワークの 1 つを使用します。

score 0 · Accepted Answer

0

I think you should use AOP (aspect-oriented programming) for this, rather than OOP.

于 2008-09-17T19:26:08.820 に答える

score 0 · Accepted Answer

私の意見では、実際にはシングルトン/グローバルメソッドはうまく機能します。できれば、グローバルなものは、コンソール出力用、データベース出力用、Windows EventLog 出力用など、さまざまなリスナー (オブザーバーパターン) を接続できる単なるフレームワークです。

ただし、過剰設計に注意してください。実際には、グローバルメソッドだけを持つ単一のクラスが非常にうまく機能することがわかっています。

または、使用している特定のフレームワークが提供するインフラストラクチャを使用することもできます。

score 0 · Accepted Answer

MicrosoftのPattern & Practices グループから提供されているEnterprise Library Logging Application Blockは、OOP 環境でロギングフレームワークを実装する好例です。ロギングアプリケーションブロックをどのように実装したかについての優れたドキュメントがあり、すべてのソースコードを自分で確認または変更することができます。

他にも同様の実装があります: log4net、log4j、log4cxx

彼らが Enterprise Library Logging Application Block を実装したLogger方法は、実際にログ操作を実行する多数の異なるメソッドを持つ静的クラスを持つことです。パターンを検討している場合、これはおそらくシングルトンパターンの優れた使用方法の 1 つです。

language-agnostic - OOP コンテキストでの適切なロギング

16 に答える 16

Related

Reference