问题标签 [single-responsibility-principle]

标题可能无法很好地描述我的问题，如果有人可以将其编辑为更合适的内容，我会很高兴。无论如何：

我得到了一个组件，它应该返回产品价格，因为它的id. 它实现了一个像这样的接口：

现在，可以从3 个不同的来源获取价格：

• 网络服务
• 直接来自网站源代码（报废）
• 作为最终后备（webservice 和网站都无法访问），返回本地数据库的最新价格

为了解决这个 3-different-sources 问题，我实现了这样的类：

当然，工厂的每个方法都会返回IProductPriceFetcher，附带说明前两个可以失败并返回null；我假设GetLocalDatabaseFetcher将始终返回有意义的对象。

我的“一般疑惑……精神”

在成功的网络服务/网站调用后，我希望将获取的价格插入本地数据库，作为未来的后备案例。现在我的问题是：上面的哪部分代码应该对此负责？它应该是返回价格的具体网络获取器之一吗？或者“聚合器”获取器（MainFetcher），因为它也知道价格的来源是什么？我应该提出一些事件吗？用数据库调用注入另一个接口？将设计更改为更好？

为什么它甚至对我来说是个问题？好吧，我试图保持代码干净（不用担心，这只是我业余时间的宠物项目 - 正是为了解决这样的问题）可能考虑到 SRP/SoC。现在我似乎在从这种心态转变时遇到了问题——我的意思是，获取网页的东西怎么可能也在进行数据库插入？哦，来吧！:)

我目前遇到了一个设计问题。

假设有一个组件层次结构。这些组件中的每一个都派生自一个Component看起来像这样的抽象类型：

现在我想为这些组件添加一些可选功能，让我们以能够在组件层次结构中搜索并在层次结构中选择组件为例。

像这样在基类中提供这些可选功能是否被认为是不好的做法：

而“搜索能力”和“选择能力”是通过例如使用策略模式在派生组件中管理的？

不知何故，这对我来说似乎违反了 SRP，但在我看来，唯一的选择是为每个可选功能提供一个接口，并且只在支持此功能的组件上实现它。

在我看来，这将有一个缺点，即每次我想检查组件是否提供特定功能时，我都必须编写这样的代码：

您会选择哪种策略，或者您有什么更好的想法？

提前致谢！

让我们作为例子：

有多少责任？1个还是4个？

设想

我正在构建一个系统，每个项目都由 2 个不同的人进行审查。每当第一个审阅者保存项目审阅时，就轮到第二个检查者完成他们的个人审阅。如果我提交了第一个评论并再次打开该项目，那么该项目将进入只读状态，因为您无法查看自己的工作。此外，如果需要更多信息，第一个审阅者可以将项目置于待处理状态，而第二个审阅者则不能。每当用户从列表中选择一个项目时，他们都会获得一个特定的审阅者卷。

到目前为止我所拥有的

每次将项目加载到编辑器中时，都会为该人分配 2 个角色之一，InitialReviewer或SecondReviewer.

我的编辑器的精简版。

问题

我遇到的问题是，我似乎无法摆脱不属于那里Save()的类内部的逻辑。Editor

问题

如何Save()从类中摆脱函数内部的逻辑Editor？它似乎违反了 SRP 原则。我认为检查当前审阅者对象是否属于类型ICanPutIntoPendingState是一个大问题。

请注意，我省略了所有逻辑，因为有很多。

假设我有一个汽车类：

我有一个自定义 CarService 类，其中包含汽车列表：

现在我想将汽车列表从文件加载到 CarService 类。我以前的 OOP 直觉是将其作为 CarService 类上的 LoadFromFile() 之类的方法。但是，当我现在正在学习 SRP 和可测试性时，我不太确定。

遵循单一职责原则，正确的设计方法是什么？我应该有一个 CarLoader 类吗？

更新

我认为解决方案在多种语言中应该是相同的，但我将使用 C++。如果我使用 C#、Java 或 python，我的问题将是相同的。

假设我有一个 MVC 操作，例如：

要测试未经授权的访问尝试的情况，应该有多少种测试方法？

即我是否编写一个测试：

还是我写两个测试：

我想问题是从技术上讲控制器违反了 SRP，但我不认为这本身就是一个问题（如果您不同意，请纠正我）。我只是不确定这如何映射到测试方法。每个方法的责任一个测试，还是通过该方法的每个单一路径一个测试？

今天，试图干掉一些代码，我提取了一些重复的 File.exists？多个辅助方法使用的代码转换为私有方法

def template_exists?(*template)并且意外地猴子修补了这个已经存在的 Rails 辅助方法。这是代码异味的一个非常明显的指标，我不需要任何继承的方法，但我继承了它们。此外，我重构的方法在这个助手中做了什么？

所以，这个助手做得太多，因此违反了 SRP（单一责任原则）。我觉得 Rails 助手本质上很难保留在 SRP 中。我正在查看的助手是其他助手的超类助手，它本身就有 300 多行。它是一个非常复杂的表单的一部分，使用 javascript 来掌握交互流程。fat helper 中的方法短小精悍，所以没有那么糟糕，但毫无疑问，它需要关注点分离。

我该怎么走？

1. 将方法分成许多助手？
2. 将辅助方法中的代码提取到类中并委托给它们？你会限定这些类（即 Mydomain::TemplateFinder）吗？
3. 将逻辑分成模块并将它们列为顶部的包含？
4. 其他方法？

正如我所看到的，没有 2 更安全 wrt 意外的猴子补丁。也许是一个组合？

代码示例和强烈的意见表示赞赏！

根据当前的实践（至少使用 WPF 和 Silverlight），我们看到通过视图模型中的命令绑定绑定的视图，或者我们至少看到在视图模型中处理的视图事件。这似乎违反了SRP，因为视图模型不仅对视图状态建模，而且对视图（用户）做出响应。其他人询问如何在不违反 SRP 的情况下构建视图模型，或者询问他们的实现是否这样做（最后一个是 MVC 中的控制器，但大致类似）。

那么当前的做法是否违反了 SRP？还是“视图模型”真的是不违反 SRP 的东西的集合？稍微解释一下，似乎我们需要知道什么是单一职责，或者如果概念中有多个职责，是否将个人职责拆分出来，符合 SRP。我不知道。

维基百科对视图模型的定义说

[T]ViewModel 是“视图的模型”，这意味着它是视图的抽象，也用于视图和模型之间的数据绑定

这对于 SRP 来说似乎已经足够好了，但后来的条目说（我强调了）

[ViewModel] 充当数据绑定器/转换器，将模型信息更改为视图信息并将命令从视图传递到模型

在一篇关于视图模型角色的Prism 博客文章中，作者说（再次强调）

它归结为视图模型是以下内容的组合：

• 视图的抽象
• 命令
• 价值转换器
• 查看状态

我确定我错过了许多定义，但它们似乎属于以下类别：

1. 建模视图状态的单一“模糊”责任（所以我们所说的状态是什么 意思）
2. 多重职责（视图状态、用户交互（即命令））
3. 单一特定职责（抽象、状态、交互、转换）的组合，因此具有单一职责：“管理所有这些东西”。

如果你很好奇，我“关心”这个，因为（2）感觉不错，但似乎与流行的实现背道而驰。

阅读所有关于单一职责原则、分解等的资料后，很难了解实体变得臃肿的警报信号应该是什么。

关于我们应该考虑最多多少种方法，或者是否有一些客观的其他标准，是否有一些好的建议/阅读某处？

在我的应用程序设计中，我通常将对象映射到数据库中的重要表。然后对象处理与该数据相关的所有内容（包括链接表）。因此，例如，我构建了一个Activity对象，具有类似 and 的属性，类似nameanddue_date的方法，以及类似 , load()and的save()方法，它们返回其他对象的（数组）。这是因为它违反了单一职责原则，所以这是“坏”的 OOP 吗？getParent()getContributors()getTeam()