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的责任是什么？

更新用户时您会怎么做？
删除用户后你会怎么做？
添加用户时该怎么办？

如果方法很简单，那么它们不会比更新数据库中的用户更多。或许，UserManager的责任可能是UserRepository。

或者UserManager的责任可能更像是用户列表。如果你看List对象。它是否使用了许多其他子类？没有。如果这是您的情况，则应将UserManager重命名为UserList对象。

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

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

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

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

1 个答案: