在实现旁边记录是否违反SRP？

在考虑敏捷软件开发和所有原理（SRP，OCP等）时，我问自己如何对待日志记录。

在实现旁边记录是否违反SRP？

我会说，yes因为该实现也应该能够运行而无需登录。那么如何更好地实现日志记录呢？我检查了一些模式，得出的结论是，最好不要以用户定义的方式违反原则，而是使用已知违反原则的任何模式的最佳方式是使用装饰器模式。

假设我们有一堆完全没有违反SRP的组件，然后我们想要添加日志记录。

• 成分A
• 组件B使用A

我们想要记录A，因此我们创建了另一个装饰有A的组件D，都实现了接口I。

• 接口我
• 组件L（系统的日志记录组件）
• 组件A实现I
• 组件D实现I，修饰/使用A，使用L进行日志记录
• 组件B使用I

优点：-我可以不使用日志就使用A-测试A意味着我不需要任何日志模拟-测试更简单

缺点：-更多组件和更多测试

我知道这似乎是另一个公开讨论的问题，但我实际上想知道是否有人使用的记录策略比装饰器或SRP违规更好。作为默认NullLogger的静态单例记录器又如何呢？如果需要syslog-logging，则在运行时更改实现对象？

是的，这是违反SRP的，因为日志记录是一个跨领域的问题。

正确的方法是将日志委托给记录器类（拦截），其唯一目的是进行记录-遵守SRP。

请参阅此链接以获取一个很好的示例：https : //msdn.microsoft.com/zh-cn/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（系统的日志记录组件）

这有一个责任：记录传递给它的信息。

组件A实现I

这有一个责任：提供接口I的实现（即，我完全符合SRP要求）。

这是关键部分：

组件D实现I，修饰/使用A，使用L进行日志记录

当这样说时，听起来很复杂，但要这样看：组件D做一件事：将A和L组合在一起。

• 组件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();
      };
   }
}