违反单一职责原则答案

【问题标题】：Single Responsibility Principle Violating违反单一职责原则
【发布时间】：2016-06-28 15:12:11
【问题描述】：

我有一个有两种方法的类。在应用程序运行时，我将操作实例作为参数发送到另一个类。

  public class Operations
{
    /// <summary>
    /// calculating the available money to use in operations
    /// </summary>
    void CalculateAvailableAmount(int x)
    {
        //making some calculation
    }

    /// <summary>
    /// sharing some values between shareholders
    /// </summary>
    void Distribute(decimal total)
    {
        //making some calculation
    }
}

上面写了之后，意识到我应该使用接口，因为方法的逻辑可以改变（我使用接口作为参数）。

public interface IOperations
{
    void CalculateAvailableAmount(int x);
    void Distribute(decimal total);
}

但是我不能确定，这两种方法并不直接相互依赖，它们都计算一些值并分配这些值。在这里，我认为 2 方法的逻辑可以在一段时间后改变。也可能我会写10多个类似上面的方法，这违反了SRP吗？在类中保留相关方法似乎更好，但另一方面我认为它可能违反 SRP 原则。哪一个更好实施？不同类和不同接口中的所有方法，或者可以吗？

谢谢

【问题讨论】：

标签： c# oop solid-principles single-responsibility-principle

【解决方案1】：

听起来您关心的不是真正 SRP，而是更多关于如何组织代码的问题。看起来您正在将类似的方法组织在一起，这是一种很好的代码组织方式。如果CalculateAvailableAmount 和Distribute 在逻辑上或功能上是相连的，那么在我看来。是的，OOP 范式通常要求根据它们所操作的数据来组织方法，但按逻辑或功能组织也是有效的（尽管它可能不是 OOP）。

单一职责原则是一个非常模糊的哲学原则。许多人在决定单个方法/类/模块的粒度或粗略程度时遇到了困难。以下只是自己的想法，绝不是一个确切的定义，因为没有确切的定义。

我认为一般的经验法则是将代码分离到它自己的模块中，如果该代码很可能独立于周围的代码发生变化。这可能意味着一个类中的一个方法或一组方法，或者一个方法中的一段代码，甚至是拆分一个库。

我认为在应用 SRP 时通常可以采取两种不同的角度。

有 YAGNI/DTSTTCPW 角度，在此角度您不会应用 SRP，直到它有意义，或者直到您 100% 对您未来有帮助。以您的示例为例，您将这两个方法保留在同一个类中，直到您意识到与周围的代码相比，其中一个或多个方法经常更改实现。那时，通过应用 SRP 将它们分开可能是有意义的......或者它可能没有。也许将代码保存在一个地方比使用 SRP 将其分段到另一个文件中更有益。或者，如果多个开发人员将在同一个模块中工作，您可能应该应用 SRP。对那个模块进行 SRP 可能是有意义的，这样你就不会踩到对方的脚趾……但也许这更多的是关注点分离而不是 SRP

或者您可以从前期设计的角度出发，猜测哪些代码块相对于周围的代码会经常更改，然后过早地将 SRP 应用到您的代码库。我对这种方法有偏见（尤其是在内部代码上），因为我认为它往往会使代码碎片化，而且我个人发现碎片化代码更难维护。其他人发现少量代码更容易理解和维护。

无论如何，我希望这会有所帮助。不要太挂在它上面。 SOLID 和设计模式旨在解决问题。如果您没有问题，请继续保持简单。如果你最终遇到问题，那么这就是重构的目的:)

【讨论】：