违反单一责任原则

本文关键字：原则 责任 单一 | 更新日期: 2023-09-27 17:52:33

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

  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原则。哪一个更好实现?在不同的类和不同的接口中的所有方法，或者这样可以吗?

谢谢

违反单一责任原则

听起来您关心的并不是真正的 SRP，而是如何组织代码。它看起来像是将方法组织在一起，这是一种很好的代码组织方式。如果CalculateAvailableAmount和Distribute在逻辑上或功能上是连接的，那么在我看来。是的，OOP范式经常要求根据它们操作的数据来组织方法，但是按逻辑或函数组织也是有效的(尽管它可能不是OOP)。

单一责任原则是一个非常模糊的哲学原则。许多人纠结于单个方法/类/模块应该是多细还是多粗。以下只是我对它的一些看法，它绝不是一个确切的定义，因为不存在确切的定义。

我认为一般的经验法则是，如果代码有很高的机会独立于周围的代码进行更改，则将代码分离到自己的模块中。这可能意味着一个类中的一个方法或一组方法，或者一个方法中的一段代码，甚至是拆分一个库。

我认为在应用SRP时，通常有两个不同的角度。

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

相反的更多的关注点分离

或者您可以从预先设计的角度出发，猜测哪些代码块相对于周围的代码将经常更改，并过早地将SRP应用于您的代码库。我对这种方法有偏见(特别是对于内部代码)，因为我认为它倾向于分割代码，而且我个人发现碎片化的代码更难维护。其他人发现小段代码更容易理解和维护。

无论如何，我希望这对你有所帮助。别太在意这件事。SOLID和设计模式是用来解决问题的。如果你没有问题，那就保持简单。如果你最终遇到了问题，那么这就是重构的目的:)

相关文章：