アプリケーション全体で静的ロギングメソッドを使用する代わりにLoggerオブジェクトを作成する理由

単純なRuby on Railsアプリケーションの例を取り上げます。Loggerアプリケーションのロードプロセス中にオブジェクトを作成します。

# in environment.rb
config.logger = Logger.new(<STDOUT | file | whatever>)

# and in our application we use this object
logger.warn "This process is taking too long to process. Optimization needed."

私の質問は、なぜロギングにクラスメソッド（または静的メソッド）を使用しないのですか？Logger.warnよりもスケーリングしませんLogger.new.warnか？または、少なくともLogger.warnより直感的ですLogger.new.warn。

Logger.newシングルトンオブジェクトであっても、どのような利点がありますか？

Javaを使用する例を次に示します。log4jを使用してからしばらく経ちましたが、私が覚えていることから、log4jロギングツール全体はXMLファイルから初期化されます。XMLファイル自体には、異なる構成（書き込み先、書き込みレベルなど）の複数のロガーを含めることができます。したがって、この場合、呼び出すロガーを指定するために、ロガーの静的メソッドではなくロガーオブジェクトを使用します。すなわち。

Logger logger = Logger.get("Network");

ネットワーク接続、ドロップされたパケットなどに関連するものを記録します

Logger logger = Logger.get("Application");

ビジネスロジック/アプリケーションに関連するものをログに記録します。少なくともlog4jでは、どのログレベルが実際に書き出されるかを構成することもできます（info、trace、warn、error、debugが利用可能なデフォルトレベルです）。

静的メソッドがある場合、できることは、標準出力やファイルなどを指す単一のロガーを構成することですが、記録するものはすべて同じ場所に移動します。ロガーオブジェクトを使用すると、ログ情報が複数のファイルに分散されるように簡単に作成できます。

Logger.newは、結果が使用される場所（クラス/ファイルの名前）を取得するファクトリです。

構成ファイルでは、プロジェクトを再コンパイルすることなく、プログラムの一部のログを記録しないレベルを決定できます。

したがって、リリースビルドの高レベルのログ（エラー）以外をすべて無効にし、デバッグしている部分の最低レベルのみをアクティブにすることができます。

静的メソッドの呼び出しは可能な限り避けてください。これは適切な依存性注入の時代遅れの代替手段であり、大規模なコードベースで役立つものではありません。

たとえば、テスト容易性を考慮してください。ロギングを静的に呼び出すと、使用するロギングクラスをテスト中のサブジェクトが制御します。制御の反転はありません。ここにモックオブジェクトや偽物を挿入する可能性はありません。ロガーをSUTに挿入することにより、ロガーをモックして挿入するオプションがあることがわかります。

議論されている種類の静的メソッド呼び出しよりもDIを使用する利点は、もちろん、テスト容易性を超えています。システムに2つの異なるロガーを配置したい場合にどうなるか、および既存のコードを編集せずにオブジェクトグラフのみを設定してアプリケーションの動作を変更するオプションを検討してください。

全体的に、DIのアプローチを試してみることをお勧めします。そのため、後でコードがテスト不能になり、扱いにくくなることはありません。