Question

我有一个有两种方法的课。在app运行时，我将Operations的实例作为参数发送到另一个类。

  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种方法＆＃39;一段时间后，逻辑可以改变。也许我会写上面的10多种方法，这是否违反了SRP？保持相关的方法似乎在一个类中更好的想法，但另一方面我虽然它可以违反SRP原则。哪一个更好实施？不同类和不同接口的所有方法，还是可以吗？

谢谢

Answer 1

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

单一责任原则是一个非常模糊的哲学原则。很多人都在努力决定单个方法/类/模块的粒度或粗糙程度。以下只是对它的想法，它绝不是一个确切的定义，因为没有确切的定义。

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

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

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

或者您可以从前期设计角度出发，猜测哪些代码块会相对于周围代码频繁更改，并过早地将SRP应用于您的代码库。我对这种方法有偏见（特别是对内部唯一的代码），因为我认为它往往会破坏代码，我个人觉得碎片代码更难维护。其他人发现少量代码更容易理解和维护。

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

违反

1 个答案: