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

问题描述 投票：1回答：2

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

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

class oop design-patterns single-responsibility-principle
2个回答
0
投票

单一责任原则的定义：

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

正如我们所看到的，我们在上面的定义中具有responsibility的定义，让我们将其表达为单词：

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

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

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

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

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

0
投票

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

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

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.