问题标签 [single-responsibility-principle]

我试图在使用 MVP 模式的场景中应用面向对象编程的原则。我有 4 个解决方案，最后两个我更喜欢。然而，大多数解决方案都打破了某些原则，如 SRP、IOC / DIP、开闭原则等。

简而言之，我希望查看者和演示者可以有一个可选的行为。此行为允许查看器拥有一个窗口或包含在一个面板中。在我看来，查看者应该了解 JFrame 和侦听器，当查看者支持所选窗口行为时，窗口演示者应该执行一些额外的操作。

你能帮我找到适合这种情况的最佳设计吗？我相信这些例子会说明需要。

解决方案 1 - 类似适配器

解决方案 2 - 使用继承

解决方案 3 - 使用窗口处理程序

解决方案 4

谢谢

目前正在对从另一个团队接管的东西进行一些代码审查，并且对应用 SRP 及其与贫乏或丰富的域模型（由 Martin Fowler 定义）的关系存在疑问。富域模型概念是拥有智能对象，不仅可以设置/获取其属性，还可以执行一些更复杂的业务逻辑。我想知道它如何适合 SRP？

假设我的模型类具有一些属性，这些属性可以公开这些道具并对其属性提供一些简单的计算。下一个要求是有可能将此对象数据存储在一些不受我控制的存储对象中，如下所示：

存储中的存储方法

如果 MyObject 有这样的存储方法，它不会违反 SRP

从这个对象的 pov 来看，能够存储它的状态是一个很好的想法。其他方法可能是在这里引入某种服务并这样做：

您能指出我可以阅读有关此问题的任何链接吗？我在这里找到了一个关于 SO 的线程，但它并没有完全回答我的问题。

在 DDD 中是如何解决的？DDD 中的模型根据定义是丰富的，并且可以被视为具有太多的职责。

我正在开发一个系统，该系统提供访问其数据库的 Web 服务并通过 .NET 类公开它。我们通常的工作方式是在需要访问数据库并直接使用该实例时创建 Web 服务类的实例；这当然完全违背了 IoC 并创建了大部分不可测试的代码。我现在正在尝试设计一种使用 IoC 的新标准工作方式，以使我们能够编写（更多）SOLID 代码。

我目前的解决方案是这样的（解释得不是很好）：

Web 服务封装在一个DatabaseConnection类中，该类将 Web 服务对象存储为受保护的成员，并提供对许多常用通用数据库调用的访问。

当我需要在实际应用程序中访问数据库时，我从该类派生（例如调用新类ApplicationDatabaseConnection）并在能够调用 Web 服务的方法中实现所需的数据库交互。

此类不直接在应用程序中使用，而是为应用程序的不同部分提供“连接器”接口，每个部分都由顶层的控制器/视图模型类表示。每当调用这些应用程序功能之一（例如从 UI）时，都会创建适当的控制器对象并将我的ApplicationDatabaseConnection对象作为相应“连接器”接口的实现传递，因此数据库访问在此时被正确封装和解耦据我所知。

我的问题是：虽然这是我在自己的代码中发现 ISP（接口隔离原则）实际使用的第一个案例（尽管我不确定这是否真的合理使用该概念），但我担心这个类可能做的太多而违反 SRP（单一责任原则）。还是“仅提供数据库访问权限，尽管针对许多不同的消费者”是一项单一职责？

为了让这一点更清楚一点，以下是相关类的大致样子：

我能想到的替代方案对我来说似乎也不理想。

为了拆分数据库访问功能，ApplicationDatabaseConnection该类只能是一个工厂类，其中包含Create用于不同连接器（后面IConnectorAFactory，IConnectorBFactory接口）的方法——但实际上并没有任何东西需要工厂模式；我只有在实例化“控制器”对象时才知道什么。

此外，实际的连接器类本质上也需要派生，DatabaseConnection因为它们需要相同的基本能力，然后（最迟）整个构造变得相当不祥。

我想我的想法在某个时刻走错了方向，现在完全走上了错误的轨道。这种解决方案的结构应该是什么样的？任何朝着正确方向的推动将不胜感激。

编辑：

@Tobias 的回答让我意识到我忘记了一个重要的细节：有两个不同版本的 Web 服务具有几乎相同的功能，但 API 完全不同，这也是必须对其进行封装的原因之一。

另一个问题是，如果我的逻辑类直接（或通过接口）访问 Web 服务，它们还关心构建 Web 服务查询的所有细节，这使得代码耦合更紧密（我们一直在生产到目前为止）并违反 SRP - 因此连接器接口的想法。

著名的面向对象编程设计的 S 代表：

单一职责原则，即一个对象应该只有单一职责的概念。

我想知道，这个原则是否可以扩展到数组、变量和程序的所有元素？

例如，假设我们有：

我们使用它来存储函数的结果，但不知何故我们使用相同的 A[100] 来检查，例如，我们已经检查和详细说明了 A 的哪些索引。这可以被认为是错误的吗？我们不应该创建另一个元素来存储，例如，我们已经检查过的索引吗？这不是暗示未来的混乱代码吗？

PS：如果我的问题无法理解，但英语不是我的主要语言，我很抱歉。如果您在理解它的要点时有任何问题，请在下面的评论中告诉我。

我一直在努力真正理解 SRP 和 SOLID，并完全理解人们为什么应用它。我还在努力自己掌握 SRP 的“艺术”。进入它，我最理解的建议是，“写下你上课的目的是什么。如果句子有单词and，但是，除了，那么它做的太多了。所以我可能写了一个名为“ActiveDirectoryHelper”的类”（我知道，很臭）有 CreateComputerObject、FindComputerObject 和 DeleteComputerObject。我认为这应该分成三个独立的类，不是吗？

但更重要的是，如果我虔诚地应用 SRP，我的 Visual Studio/C# 项目中不会得到几十个类 .cs 文件吗？如果是这样，如果它必须是这样的话，你如何组织你的项目？

非常感谢

如问题所示，

正如函数名称所示，我们使用 IsNullOrEmpty 或 IsNullOrWhiteSpace 等字符串函数，这些函数不止一项工作，这不是违反SRP吗？

而不是 string.isValid(Enum typeofValidation) 而不是使用策略模式来选择正确的策略来验证。

或者在实用程序类或静态类中违反 SRP 是否完全可以。

在 ASP.NET MVC 中，在 [HttpPost] 方法上，MVC 运行时会根据字段名称自动将数据从前端的表单字段映射并传输到视图模型中。

如何在 ASP.NET WebForm 中完成同样的事情？

例如，我有一个名为 Person 的对象，具有 FirstName 和 LastName 属性。

我有一个 WebForm 页面，其中的 Textbox 控件分别带有 FirstName 和 LastName。

在表单上按下提交时，有没有办法在代码隐藏的 Button_Click 事件中自动将 FirstName 和 LastName 绑定到 Person 对象？

我们正在开发一个网站，并且我们有一个控制器来处理模型（例如 Country）的 CRUD。仅允许管理员执行 CRUD 操作。但是，我们还希望控制器提供一个 JSON 选择实体列表来填充下拉列表。这种模式存在于整个应用程序中。

这意味着我们不能使用标准的授权属性来限制管理员在控制器入口处的访问。我们需要用特定的授权属性来装饰每个动作。

我们在单个控制器上需要多个授权级别这一事实是不是一个不好的信号？这是否表明我们违反了 SRP？

处理许多控制器与仅需要由管理员更新但为所有授权用户提供 JSON 选择列表的实体这一事实的最佳模式是什么？

谢谢

刚才我输入这个问题时，出现了一个有趣的线程。我不认为它回答了我的问题。

我一直在使用 .NET MVC3 进行大量工作，希望有一个贫血模型。视图模型和编辑模型最好作为愚蠢的数据容器，您可以将它们从控制器传递到视图。任何类型的应用程序流都应该来自控制器，视图处理 UI 问题。在 MVC 中，我们不希望模型中有任何行为。

但是，我们也不希望控制器中有任何业务逻辑。对于较大的应用程序，最好将域代码与模型、视图和控制器（以及通常的 HTTP）分开并独立于模型、视图和控制器。因此，有一个单独的项目首先提供域模型（具有实体和值对象，根据 DDD 组合成聚合）。

我已经做了一些尝试，从一个贫乏的模型转向更丰富的域代码模型，我正在考虑放弃。在我看来，拥有既包含数据又包含行为的实体类违反了 SRP。

以网络上一个非常常见的场景为例，撰写电子邮件。给定一些事件，域有责任在给定 EmailTemplate、EmailAddress 和自定义值的情况下编写一个 EmailMessage 对象。模板作为具有属性的实体存在，并且自定义值作为用户输入提供。为了论证，我们还假设 EmailMessage 的 FROM 地址可以由外部服务 (IConfigurationManager.DefaultFromMailAddress) 提供。鉴于这些要求，富域模型似乎可以让 EmailTemplate 负责编写 EmailMessage：

这是我对富域模型的尝试之一。但是，在添加此方法后，EmailTemplate 负责包含实体数据属性和撰写消息。它大约有 15 行长，似乎分散了全班学生对成为 EmailTemplate 的真正含义的注意力——IMO 只是存储数据（主题格式、正文格式、附件和可选的发件人/回复地址）。

我最终将此方法重构为一个专门的类，该类的唯一责任是根据前面的参数编写一个 EmailMessage，我对此更满意。事实上，我开始更喜欢贫血领域，因为它帮助我保持职责分离，使类和单元测试更短、更简洁、更专注。似乎使实体和其他数据对象“没有行为”可以很好地分离责任。还是我在这里偏离轨道？

我目前正在建模一个负责管理版税支付的系统。版税可能很简单：

• 支付作者 A 收入的 15%

或与以下任何一个一样复杂：

• 向作者 B 支付 15% 的收入，最多售出 1000 件，然后支付收入的 12%
• 每售出 1000 件，还需向作者 B 支付 1.50 美元

或者：

• 向作者 C 支付前 1,000 美元收入的 15%，然后支付收入的 12%

简而言之，付款可以是每次销售的固定金额或收入的百分比。付款条件可以基于销售数量或收入。我试图通过指定支付范围和支付值的类型来设计一个包含所有这些灵活性的类（它与幕后的数据库表密切相关）。但是，我担心我可能试图让这门课做太多事情，如果我们将来需要适应其他场景，可能会让自己陷入困境。我正在寻求替代设计方法的建议。

任何建议，将不胜感激。

2012 年 5 月 9 日更新：

我应该提到，这些规则必须保存到 SQL Server 数据库中。