违反单一职责原则

Question

我有一个 class 有两种方法。当 app 运行我将 Operations 实例作为参数发送给另一个 class。

  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？在 class 中保留相关方法似乎是更好的主意，但另一方面我认为它可能违反 SRP 原则。哪个更好实施？不同 classes 和不同接口中的所有方法，或者可以吗？

谢谢

Answer 1

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

单一职责原则是一个非常模糊的哲学原则。许多人都在为决定单个 method/class/module 的粒度或粗糙度而苦苦挣扎。以下只是自己的思考，绝不是一个确切的定义，因为没有确切的定义。

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

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

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

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

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

违反单一职责原则

Single Responsibility Principle Violating

c#

oop

single-responsibility-principle

solid-principles