是否有任何策略来划分应用 SRP 的责任？答案

【问题标题】：Is there any strategy to partition the responsibilities to apply SRP?是否有任何策略来划分应用 SRP 的责任？
【发布时间】：2020-03-29 02:04:07
【问题描述】：

是否有任何策略来划分类以应用单一职责原则？

在一个中等规模的团队中，我们正在开发一个可穿戴管理器应用程序，它可以连接不同类型的可穿戴设备，例如 Wearable1 和 Wearable2（一次连接一个连接）。每个可穿戴设备都有不同类型的数据交换功能。所以我决定根据可穿戴类型来划分责任。即

interface Manager {
    // common functionalities
}

class Wearable1manager implements Manager {
    // Manages wearable1 specific functionalities
    // as well as wearable1 related capabilities
}

class Wearable2manager implements Manager {
    // Manages wearable2 specific functionalities
    // as well as wearable2 related capabilities
}

我的一位同事否认我的设计，称它违反了Single Responsibility Principle (SRP)，因为与能力相关的功能应由单一能力管理器处理。他的提议就像，

interface Manager {
    // common functionalities
}

class WearableManager implements Manager {
    // Manages wearable1 specific functionalities
    // as well as wearable2 specific functionalities
}

class CapabilityManager implements Manager {
    // Manages wearable1 related capabilities
    // as well as wearable2 related capabilities
}

基本上，我发现我们都在强调应用单一职责原则，但我们划分职责的想法是基于不同的方面。当我需要根据哪个职责来决定我应该对类进行划分时，我经常发现我处于这种危急情况。所以我的问题是，

对于 OOP 设计，是否有任何特定的指导方针有助于决定划分类以应用 SRP？还是这纯粹依赖于经验？我希望应该有具体的步骤来分析和解决这种混乱。感谢有经验的人提出建议。

【问题讨论】：

这两种设计看起来都不对。这些“经理”类用于是什么？
@Matt 管理器用于处理功能。虽然它应该包含可穿戴实例和其他东西。我只是向 MWE 展示了面对决策困境的实际问题。
这很模糊。 “经理”类通常管理事物或事件的集合、聚合状态、跟踪添加和删除等——与人类“经理”所做的事情相同。 SRP 意味着每个组件为一个老板做一项工作。我没有看到任何需要完成的工作或任何需要完成的老板。没有它，你只是将代码分割成多个文件，而不是设计软件。从您的应用程序的目的来看，您似乎可能需要一个 WearableManager 类 + 管理用户拥有的可穿戴设备集合的接口。

标签： class oop design-patterns single-responsibility-principle

【解决方案1】：

没有“责任”的定义。因此，没有这样的策略。但是，有：1) 几乎没有常识，2) 对你正在工作的环境的感觉。

根据我的个人经验，正确的问题是“我为什么需要更改此代码？”。如果有不止一个（业务？）原因，那就是更多思考的触发因素。

【讨论】：

如果没有responsibility的定义，那么SRP原则到底是如何工作的？
@SazzadHissainKhan，没有“爱”的定义，也没有“善良”的定义，尽管两者都很好。
在 SRP 方面的责任可以定义为功能的划分，软件能力的逻辑约束部分。因此，您可以抽象地定义概念，但是当您必须在给定软件上应用此原则时，需要您定义具体职责。
Sereja，你陷入了涅槃谬论（如果你不能完美地完成某事，就避免做某事）。这是一个逻辑谬误。当然，我们可以定义什么是功能。在 Internet 上进行简单搜索会为您提供数十种定义。但是如果我将它们粘贴在这里，您会注意到它们是基于另一个概念定义的，并且会引用它的定义。轮到我给你这个定义，这个过程将被重复。
我们正在处理复杂的概念，开始定义什么是功能或我们用来定义它的概念不在我们讨论的范围内。我们可以永远玩那个，但我没有时间。高中或学院/大学的教授负责定义和解释这些概念。我们专业的程序员必须专注于其他事情，教授这些简单的概念并不是我们的强项。

【解决方案2】：

单一职责原则的定义：

单一职责原则是计算机编程规定每个模块、类或函数 [1] 应该对所提供功能的单个部分负责由软件承担，责任应完全由由类、模块或函数封装。它的所有服务应该与该责任密切相关。罗伯特·C·马丁将这一原则表达为“一个阶级应该只有一个理由 change,"[1] 虽然，由于对“原因”一词的混淆，他最近表示“这个原则是关于人的。（演员）”[2]

如我们所见，我们在上面的定义中有责任的定义，让我们将其表述为文字：

责任等同于功能的逻辑绑定部分由软件提供。

所以，如果你有与能力相关的功能，你应该在单个类/模块中实现这些功能，因此你的同事是对的，你的初始代码将能力的实现分为两个不同的 Wearable Manager 类，这违反了原则，因为与能力相关的功能是一种责任。

不过，您也有必要指出不同的可穿戴管理器具有不同的功能。为了解决这个问题，您需要一个可穿戴管理器实例的属性来识别它具有哪些功能。这可以是一个数组、一个字符串甚至是第三个管理器的实例，用于处理可穿戴设备的功能，因为您可以将功能和可穿戴设备之间的关系定义为单独的职责。

SRP 取决于您的职责。您需要定义您的案例中的责任。为此，您需要将您的功能划分为逻辑绑定的分区（职责），然后一切都将就位。但是，如果你和你的同事做了不同的划分，那么你们两个脑子里就有不同的责任实体，讨论这个是一个明智的主意。

责任作为一个概念显然是可以定义的，但是，定义您的职责是您和您的同事的工作。对问题的经验和理解越多，分区就越好。

【讨论】：