S in SOLID -如何/在哪里划线？

Question

因此，单一责任原则类应该为了一个且只有一个原因而改变，但是你如何有效地判断责任到底是什么。简单的例子：

public class UserManager
{
    public void AddUser() { }
    public void RemoveUser() { }
    public void UpdateUser() { }
}

可以争辩说，其中任何一个都会破坏SRP。因此，您最终对其中的两个使用了DI，并最终得到了以下结果：

public class UserManager
{
    private UserRemover _remover;
    private UserUpdater _updater;

    public UserManager(UserRemover remover, UserUpdated updater)
    {
        _remover = remover;
        _updater = updater;
    }

    public void AddUser() { }
    public void RemoveUser() { }
    public void UpdateUser() { }
}

如果有更多与用户管理相关的方法怎么办？会沿着这条路走下去，并继续在构造函数中传递额外的依赖项吗？对于任何拥有多个公共方法的类，都可以认为它违反了SRP。你是用常识选择第一个选项，还是纯粹地选择第二个选项？

Answer 1

单一责任原则

答: UserManager的职责是什么？

1. 更新用户时怎么办？
2. 删除用户时怎么办？
3. 添加用户时怎么办？

如果这些方法非常简单，那么它们所做的仅仅是更新数据库中的用户。也许，UserManager的责任可能是UserRepository。

或者，也许UserManager的职责更像是一份用户列表。如果你看一下列表对象。它使用了很多其他的子类吗？不是的。如果这是您的情况，则应将UserList对象重命名为UserManager。

在这种情况下，您不确定SRP原则的主要原因是因为“经理”这个词没有任何具体的含义。试着找一个更好的名字，你会找到答案的。如果您的类需要访问更具体的对象，它将显示在名称中。

此外，您的单元测试应该有助于识别问题。单元测试是揭开这种神秘面纱的好方法。

此外，没有任何纯粹主义者会过度设计这种问题;)记住，过早优化是所有邪恶的根源。