这个课程违反了单一职责原则吗？

Question

我已经编写了关于用户的UserService类（在逻辑层，而不是持久层中），它包含这些方法。你知道吗

• 创建
• 补丁
• 删除
• 找一个
• 获取\u列表

使用这些方法的类是否违反了SRP？你知道吗

python
class UserService:

    repository: Repository

    def create(...):
        self.repository.save(...)

    def patch(...):
        self.repository.patch(...)

    def delete(...):
        self.repository.delete(...)

    def get_one(...):
        return self.repository.get(...)[0]

    def get_list(...):
        return self.repository.save(...)

如果这有很多责任，我如何分配类？你知道吗

Answer 1

单一责任原则是个棘手的问题。你知道吗

让我们从定义什么是软件系统上下文中的责任以及责任的范围开始。你知道吗

责任有许多不同的形式。你认为的每件事都可能是一种责任，你的代码中的每件事都可能有责任。你知道吗

• 你的模块有责任。如果您有计费模块此模块负责处理计费。

• 现在，如果您深入研究，您的计费模块可以包含多个层。每一层都有特定的职责。演示、业务逻辑等

• 进一步缩小范围，我们发现每一层都由不同的类和/或函数组成。他们每个人都有自己的责任。

• 现在我们来看看函数和里面的代码。在那里你可以有多个语句，如果，for，=etc，每个语句都在做一些有责任的事情。如果您分析您的语句，您将注意到一个函数/方法有多少职责。

如果你有UserRepository，它唯一做的就是与DB通信或者在你的应用程序和ORM之间进行调解，那么它就有这个职责。这并不意味着Repository将有一个单一的方法。为了遵守SRM，您的UserRepository应该只有处理与users相关的DB通信的方法。它不应该包含任何业务逻辑。你知道吗

如果您有一个UserService，并且它只有与用户相关的操作，那么这个服务将遵循SRP，因为它的职责是让操作与Users相关。你知道吗

现在SRP中有一个非常棘手的部分。

为了让您的UserService完成它的工作，需要调用UserRepository。如果这个服务创建用户，然后将他们添加到数据库中，这不意味着UserService有责任保存新用户吗？你知道吗

我们看到，我们在这方面有两个不同的责任。你知道吗

• 知道如何做一件事的责任。UserRepository知道如何与ORM或DB通信并保存新用户。

• 当事情需要做的时候说出来的责任。UserService知道User应该什么时候保存而不是应该如何或在哪里保存。

你有两个不同的责任。如果您的持久性发生了变化，因为您将改变how和/或where，那么您将只改变存储库实现，但服务不会受到影响。如果您的业务逻辑发生了变化，那么您将在时更改，因此服务将更改，而不是存储库。你知道吗

另一件事是当对象的接口变大时。你知道吗

人们开始怀疑这个大型接口是否遵循了单一的职责？你知道吗

如果所有的方法都是内聚的，那么它就是内聚的。这意味着某个东西的大小并不意味着它违反了SRP。它可能违反其他原则，如Interface Segregation Principle，但这并不意味着它违反了SRP。它只是很难使用，阅读，修改等，在这种情况下，你可以分解成多个更小的东西。你知道吗

下面是一个例子。假设您存储应用程序的设置。您可以设计一个接口ISettingsProvider，该接口具有所有设置的属性，并将导致一个包含50个方法的接口。如果我们将责任定义为保存设置，则此接口不会违反SRP。如果我们将责任定义为保存应用程序特定部分的设置，那么这个接口将违反它。你知道吗

上面的例子的目的是显示SRP有时可能是主观的，并且粒度很重要。如果你定义如果你的职责范围更小，那么为了遵守SRP，你需要设计更小的接口，类的函数。你知道吗

它是一个树形结构。顶层作用域更宽，由更细粒度的作用域组成，以此类推。根据您查看的位置，您的组件/对象/模块可能会附着在SRP上。你知道吗

如果在一个大类中有一个计费模块，那么从系统的角度来看，模块非常适合SRP。从模块内部的职责来看，实现该模块的类将包含业务逻辑、数据库通信代码、查询构建等，并且该类将违反SRP。你知道吗