问题标签 [single-responsibility-principle]

我已经向我的团队介绍了 SOLID 原则，他们理解并且对使用这些原则感到兴奋。

我给了他们几个已经被重构以使用这些原则的项目。我看到的最大问题是他们是否很难看到项目中非常松散耦合的类之间的联系。即使我创建了一个类图，它也不会显示任何连接。我所指的一个特定项目也使用依赖注入和 XML 配置来实现。虽然这样做的目的是让他们更难找出正在使用的类。

直观地显示类之间的关系以及它们在项目中的使用方式的最佳方式是什么？！

编辑：2008/10/24 8:40 PM

根据 UML 注释，我尝试使用内置的 Visual Studio 类图来构建应用程序模型。我可以给出每个接口的描述，但仍然不确定它们是否明确连接。

我试图通过将步骤（验证、附加相关内容、格式、发送）划分为可以更容易测试、记录和更新的单独类来重构一些“发送电子邮件”代码。

作为其中的一部分，我必须想办法让操作将验证或暂时错误（“该项目已删除”）传回发起者，以便它可以向用户询问更多信息或告诉他们坏消息. 这是线程采用的路径（是的，涂鸦）

所以你是一个深思熟虑的人，在“返回”、“例外”或“背景”之间……哪一个让你最开心？

A. 在任何问题上抛出异常，让控制器划分它可以优雅处理的和知道我的“蜂鸣器”的那些。

B.返回某种 Result<T>类来携带操作的产品（电子邮件）和各种操作的枚举结果。

C. 将上下文传入/传出所有步骤，在这些步骤中可以指示他们无法处理的任何参数，并保持方法签名非常简单。

D. 儿子，你想多了。这就是你要做的事情：<YourSpecialJujuHere/>

感谢您的所有贡献，你们一起摇滚。

单一职责原则和关注点分离有什么区别？

我在决定班级责任时遇到了问题。
我有 3 个 html 表单：

1. 对于每个表单，都有一个 html 模板，其中包含一些文本和要包含的表单的标记
2. 每个表单都需要验证，如果有错误，则需要重新显示 (1) 中的模板和表单，以及一些错误消息。只有一些字段在不同的表单中是通用的。
3. 如果没有错误，则需要邮寄结果消息。每个表单都有一个结果邮件模板。

我发现很难为这个问题决定一个好的班级计划。一种可能性是按功能分离类

• CheckFormData：检查表单数据
• DisplayForm：显示有/无错误的表单（或者也分开这个？）
• 电子邮件表格：电子邮件表格。

我对此不确定。关于一种特定形式的领域的知识分散在各个类别中。

有一些工作流程。也许我还应该有一个工作流类：

对于每种表单类型（请记住，其中有 3 个），我需要一个

1. CheckForm,
2. EmailForm和
3. DisplayForm班级。

3*3 = 9 个类 + 3 个基类 = 12 个类。
此外，您想将正确的 CheckForm-subclass 和 EmailForm-subclass 注入工作流程，它们都需要具有相同的表单类型。也许我们需要为此创建一个 FormWorkFlowFactory。这样一共有13 个类。

现在我觉得我做错了可怕的事情。如果我有FormSubmitWorkFlow一个模板方法类，我可以创建 3 个子类，但每个子类会混合不同的职责。

你如何改进这一点，你能激发你的答案，即什么方法引导你得到答案？

编辑：虽然当前唯一的答案很有用，但很高兴看到同意它的人的一些投票，或者我想听到社区提供更好的解决方案。我是唯一一个赞成这个答案的人。这个问题可以使用更多的输入，所以请随时提供:-)

这更像是一个理论问题。日志记录应该驻留在一个主要目的不是日志记录的类中吗？

这是一个简单的界面，用于对数字进行计算的任何内容。

这是执行计算并进行一些日志记录的 ICalculation 接口的实现。我相信这是一种非常务实的做法。除了构造函数接受我们通常不希望在计算域中看到的东西之外，内联日志记录可以说是非侵入性的。

从 RealIntenseCalculation 中删除所有日志记录代码后，代码现在似乎具有明确的单一职责。

好的，所以我们删除了真正强烈计算的记录其内部的能力。我们怎样才能找到一种方法来外部化该功能。输入装饰器模式。

通过创建一个装饰 ICalculation 的类，我们可以将日志重新添加到组合中，但这样做会损害在真正强烈计算的私有方法中发生的一些更精细的日志记录。

拥有日志装饰器还有哪些其他可能的优点和缺点？

我从一位同事那里得到了一个设计的回击，我想知道在这种情况下谁是正确的 SRP 应用是否存在共识。

我认为 SRP 主要与较低级别的设计细节有关，例如类责任。随着抽象级别的提高，我相信 SRP 仍然是相关的，但单一职责的定义也必然会向更高级别的抽象移动。

在我的具体情况下，在我看来“处理 foo、存储其结果并提供对这些结果的访问”的服务具有“foo 处理子系统”的单一责任，但是同事不同意并将其视为 2-3责任。我的情况是，如果您总是将单一职责分解为微小的细节，那么拥有“银行”就违反了 SRP，因为它“持有资金、维护账户、出售抵押贷款……”。

在我目前正在使用的系统中，我通过将域业务规则的验证与持久性约束分开来遵循 SRP（我认为！）。让我们使用过度使用的客户示例。假设客户必须具有有效的邮政编码、街道地址和姓名才能满足系统的业务规则。让我们进一步说，客户选择的用户名在所有客户中必须是唯一的，我将其定义为持久性约束。请考虑以下“未准备好投入生产”伪代码：

上面定义的类可能会连接到一个服务类中，如下所示：

我对这种方法的主要担忧是 CustomerDao 的未来使用者必须知道在 SaveCustomer() 之前调用 IsValidForPersistence()，否则无效数据会被保留。我可以在 SQL 级别创建 DB 约束来防止这种情况，但这感觉像是一个杂物。

似乎 IsValidForPersistence() 应该移动到 CustomerDao.SaveCustomer() 但随后我必须重构 SaveCustomer() 的签名以包含对 ValidationErrors 类的引用。在我深入进行重构之前，我想从其他人那里获得一些关于处理这些问题的常见/首选模式的反馈。

谢谢

我有关于表单验证和业务验证的问题。我看到很多框架使用某种形式的验证库。您提交一些值，库会验证表单中的值。如果不正常，它会在您的屏幕上显示一些错误。如果一切按计划进行，这些值将被设置到域对象中。在这里，这些值将被验证，或者更好地说，应该（再次）验证。验证库中很可能是相同的验证。我知道 2 个 PHP 框架具有这种构造 Zend/Kohana。

当我查看编程和一些原则时，例如不要重复自己(DRY) 和单一职责原则(SRP)，这不是一个好方法。如您所见，它验证了两次。为什么不创建进行实际验证的域对象。

示例：提交带有用户名和电子邮件表单的表单。用户名字段和电子邮件字段的值将填充到 2 个不同的域对象中：用户名和电子邮件

这些对象验证它们的数据，如果无效则抛出异常。你同意？您如何看待这种方法？有没有更好的方法来实现验证？我对很多处理这些东西的框架/开发人员感到困惑。他们都是错的还是我错过了一点？

编辑：我知道还应该有客户端类型的验证。在我看来，这是一个不同的球赛。如果您对此有一些意见以及处理此类事情的方法，请提供。

我有一个数据访问层，它将应用程序的其余部分从持久性技术中抽象出来。现在的实现是 SQL 服务器，但这可能会改变。无论如何，随着我的表的增长（现在大约 40 个表），我发现这个主要的数据访问类变得越来越大。此数据访问层的接口是您可能想要获取数据的任何问题

这背后的实现是基本的 SQL 存储过程，运行适当的查询并在类型化集合中返回结果

这将继续增长和增长。它非常易于维护，因为没有真正打破单一职责，但该类现在有超过 2000 行代码。

所以问题是，由于确定的类大小（并且没有真正的概念耦合），这是否应该被分解，如果是这样，那么抽象的维度或级别是什么。

我正在重构几个月前编写的一些代码，现在我发现自己创建了很多小类（很少的属性、2-4 个方法、1-2 个事件）。

这是应该的吗？或者这也有点代码味道？

我的意思是，如果一个类确实需要很多方法来履行它的职责，我想这就是它的样子，但我不太确定很多小类是不是特别好的实践？