実装の隣のロギングはSRP違反ですか？

アジャイルなソフトウェア開発とすべての原則（SRP、OCPなど）を考えるとき、ロギングをどのように扱うかを自問します。

実装の隣のロギングはSRP違反ですか？

yes実装はロギングなしで実行することもできるはずだからです。それでは、より良い方法でロギングを実装するにはどうすればよいですか？いくつかのパターンを確認し、ユーザー定義の方法で原則に違反するのではなく、原則に違反することが知られているパターンを使用する最良の方法は、デコレータパターンを使用することであるという結論に達しました。

SRP違反のない完全に多数のコンポーネントがあり、ロギングを追加するとします。

• コンポーネントA
• コンポーネントBはAを使用します

Aのロギングが必要なので、Aで装飾された別のコンポーネントDを作成し、両方ともインターフェースIを実装します。

• インターフェースI
• コンポーネントL（システムのロギングコンポーネント）
• コンポーネントAはIを実装します
• コンポーネントDはIを実装し、Aを装飾/使用し、ロギングにLを使用します
• コンポーネントBはIを使用します

利点：-ロギングなしでAを使用できます-Aをテストすると、ロギングモックが不要になります-テストが簡単になります

欠点：-より多くのコンポーネントとより多くのテスト

これはもう1つの公開討論の質問のように思えますが、デコレータやSRP違反よりも優れたログ戦略を誰かが使用しているかどうかを実際に知りたいです。デフォルトのNullLoggerであり、syslogロギングが必要な場合、実行時に実装オブジェクトを変更する静的シングルトンロガーはどうでしょうか。

はい、それはロギングが横断的な関心事であるため、SRPの違反です。

正しい方法は、ログをロガークラス（インターセプション）に委任することです。この唯一の目的は、ログを記録することです（SRPに準拠）。

良い例については、このリンクを参照してください：https : //msdn.microsoft.com/en-us/library/dn178467%28v=pandp.30%29.aspx

以下に短い例を示します。

public interface ITenantStore
{
    Tenant GetTenant(string tenant);
    void SaveTenant(Tenant tenant);
}

public class TenantStore : ITenantStore
{
    public Tenant GetTenant(string tenant)
    {....}

    public void SaveTenant(Tenant tenant)
    {....}
} 

public class TenantStoreLogger : ITenantStore
{
    private readonly ILogger _logger; //dep inj
    private readonly ITenantStore _tenantStore;

    public TenantStoreLogger(ITenantStore tenantStore)
    {
        _tenantStore = tenantStore;
    }

    public Tenant GetTenant(string tenant)
    {
        _logger.Log("reading tenant " + tenant.id);
        return _tenantStore.GetTenant(tenant);
    }

    public void SaveTenant(Tenant tenant)
    {
        _tenantStore.SaveTenant(tenant);
        _logger.Log("saving tenant " + tenant.id);
    }
}

利点が含まれます

• ログなしでこれをテストできます-本当のユニットテスト
• 実行時でも簡単にロギングのオン/オフを切り替えることができます
• TenantStoreファイルを変更することなく、他の形式のログをログに置き換えることができます。

私はあなたがSRPをあまりにも真剣に受け止めていると言います。コードがきちんと整理されていて、ロギングがSRPの唯一の「違反」である場合、他のすべてのプログラマーの99％を上回っています。

SRPのポイントは、異なることを行うコードがすべて混同される恐ろしいスパゲッティコードを避けることです。ロギングと機能コードを組み合わせても、警告音は鳴りません。

いいえ、SRPの違反ではありません。

ログに送信するメッセージは、周囲のコードと同じ理由で変化するはずです。

SRP違反とは、特定のライブラリを使用してコードに直接ログインすることです。ロギングの方法を変更することにした場合、SRPはビジネスコードに影響を与えるべきではないと述べています。

Logger実装コードから何らかの抽象化にアクセスできる必要があります。実装で言うべきことは、「このメッセージをログに送信する」ことだけです。ロギングの正確な方法（タイムスタンプを付けても）を決定することは、実装の責任ではありません。

その場合、実装は、メッセージの送信先のロガーがであるかどうかも知らないはずNullLoggerです。

そうは言った。

横断的関心事としての伐採を早すぎないようにします。実装コードで発生する特定のイベントをトレースするためのログの発行は、実装コードに属します。

横断的な関心事であるOTOHとは、実行トレースです。すべてのメソッドでロギングが開始および終了します。これを行うにはAOPが最適です。

ロギングはしばしば分野横断的な懸念事項と考えられているため、AOPを使用してロギングを実装から分離することをお勧めします。

インターセプターまたは何らかのAOPフレームワーク（JavaのAspectJなど）を使用してこれを実行する言語に応じて。

問題は、これが実際に面倒な価値があるかどうかです。この分離により、プロジェクトの複雑さが増す一方で、メリットはほとんどないことに注意してください。

これは問題ありません。かなり標準的なロギングデコレータについて説明しています。あなたが持っている：

コンポーネントL（システムのロギングコンポーネント）

これには1つの責任があります：渡される情報を記録する。

コンポーネントAはIを実装します

これには、インターフェースIの実装を提供するという1つの責任があります（つまり、Iが適切にSRPに準拠していると仮定します）。

これは重要な部分です。

コンポーネントDはIを実装し、Aを装飾/使用し、ロギングにLを使用します

そのように述べられたとき、それは複雑に聞こえますが、このように見ます：コンポーネントDは、AとLを一緒にするという1つのことを行います。

• コンポーネントDはログに記録しません。それをLに委任します
• コンポーネントDはI自体を実装しません。それをAに委任します

コンポーネントD の唯一の責任は、Aが使用されたときにLに通知されるようにすることです。AとLの実装は両方とも別の場所にあります。これは完全にSRPに準拠しているだけでなく、OCPのきちんとした例であり、デコレーターのかなり一般的な使用法です。

重要な注意点： DがロギングコンポーネントLを使用する場合、ロギング方法を変更できる方法で使用する必要があります。これを行う最も簡単な方法は、Lによって実装されるインターフェイスILを持つことです。

• コンポーネントDはILを使用してログを記録します。Lのインスタンスが提供されます
• コンポーネントDはIを使用して機能を提供します。Aのインスタンスが提供されます
• コンポーネントBはIを使用します。Dのインスタンスが提供されます

そうすれば、他のものに直接依存するものは何もないので、簡単に交換できます。これにより、変更への適応が簡単になり、システムの一部を簡単にモックできるため、ユニットテストを実行できます。

もちろん、横断的な懸念があるため、SRPの違反です。ただし、アクションを実行してロギングを構成するクラスを作成できます。

例：

class Logger {
   ActuallLogger logger;
   public Action ComposeLog(string msg, Action action) {
      return () => {
          logger.debug(msg);
          action();
      };
   }
}