Question

是否有任何策略可以将类划分为适用单一职责原则？

在一个中等规模的团队中，我们正在开发可穿戴式管理器应用程序，该应用程序可以与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？还是纯粹依赖于体验？我希望应该有特定的步骤来分析和解决这种混乱。感谢经验丰富的建议。

Answer 1

没有“责任”的定义。作为结果，没有这样的策略。但是，有：1）几乎没有常识，2）对您所担心的上下文的感觉。

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

Answer 2

单一责任原则的定义：

单一责任原则是计算机编程指出每个模块，类或函数[1]应遵循的原则对所提供功能的一部分负责由软件负责，该责任应完全由由类，模块或函数封装。其所有服务应与这种责任紧密地联系在一起。罗伯特·马丁表示该原则为：“一个班级只有一个理由改变” [1]，但由于围绕“原因”一词的混淆，他最近又说“这个原则是关于人的。（演员）” [2]

如我们所见，在上面的定义中我们已经定义了 responsibility （责任），让我们将其表达为单词：

责任等于功能的逻辑约束部分由软件提供。

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

但是，您还有一点要说明不同的可穿戴管理器具有不同的功能。为了解决这个问题，您将需要可穿戴管理器实例的属性，以识别其具有的功能。这可以是处理可穿戴设备功能的数组，字符串或什至是第三方管理器的实例，因为您可以将功能和可穿戴设备之间的关系定义为单独的职责。

SRP取决于您的责任。您需要定义案例中的职责。为此，您需要将功能划分为逻辑绑定的分区（职责），然后从那里将所有内容放到适当的位置。但是，如果您和您的同事进行了不同的划分，那么你们两个人的脑海中就有不同的责任实体，那么讨论这个问题将是一个明智的主意。

责任显然是可以定义的，但是，定义您的职责是您和您同事的工作。对问题的了解和了解越多，分区就会越好。

是否有任何策略可以划分应用SRP的职责？

2 个答案: