问题标签 [single-responsibility-principle]

在我正在编写的应用程序中，我有一个 Policy 类。有 4 种不同类型的策略。每个策略都根据其他策略加权，例如 PolicyA > PolicyB > PolicyC > PolicyD。

谁负责执行逻辑来确定一个策略是否大于另一个？我最初的想法是重载 > 和 < 运算符并在 Policy 类型本身中实现逻辑。

这是否违反 SRP？

Information-Expert、Tell-Don't-Ask和SRP通常作为最佳实践一起被提及。但我认为他们是矛盾的。这就是我要说的。

支持 SRP 但违反 Tell-Don't-Ask & Info-Expert 的代码：

支持 Tell-Don't-Ask 和 Info-Expert 但违反 SRP 的代码：

请告诉我这些做法如何和平共存。

术语的定义，

• 信息专家：具有操作所需数据的对象应承载操作。

• Tell Don't Ask：不要为了工作而向对象索取数据；告诉对象做这项工作。

• 单一职责原则：每个对象都应该有一个狭义的职责。

我知道“班级有一个改变的理由”。现在，那到底是什么？是否有一些气味/迹象可以表明该班级没有单一责任？或者真正的答案是否可以隐藏在 YAGNI 中，并且只在你的类第一次更改时重构为单一职责？

我正在阅读很多关于 OOP 设计中好的和坏的做法。很高兴知道您的设计是坏的还是好的。但是你如何从糟糕的设计变成优秀的设计呢？我已将接口 (xaml) 和代码隐藏从主要的业务逻辑类中分离出来。最后一堂课越来越大了。我试过把它分成更小的班级，但我现在卡住了。关于如何拆分大班的任何想法？主类有 1 个不同类型的数据列表。我正在对总数进行计算，但也在对个别类型进行计算。我有方法来执行这些计算，这些计算是从代码隐藏中处理的事件中调用的。有什么想法可以从这里开始吗？

附加信息：

我们已经进入这个项目大约 6 个月了。我多年来一直使用面向对象的语言（首先是 c++、java，现在是 c#），但从未参与过像这样的大型项目。我相信我们一开始就犯了一些错误，我认为我们需要纠正这些。目前我无法具体说明这个项目的任何细节。我要订一两本关于设计的书。如果我将所有课程分开，我如何将它们重新组合在一起？也许以这种方式继续到第一个版本并在此之后重建部分以进行第二个版本会更好？

我们目前正在使用大约 7 项服务。那里相当大。

有人对单一责任原则和 WCF 服务有任何经验吗？这是否意味着你最终会得到很多小合同？如果是这样，您如何在应用程序中管理这些？

如果我将我的对象分解为“单一职责”，是否有一个基本的想法是类似的对象应该一起存在还是分开存在，例如，如果我有

将所有这些都存在于内部，但通过接口松散耦合到一个拥有的 Employee 类，是不是很糟糕：

还是更多地考虑在代码中将这些类完全分开（或尽可能地分开）？或者这两种方法都是 SRP 的有效用法？

编辑：我不想批评示例中给出的对象的可行性，我只是为了说明问题而编造出来的。我同意数据、休假和工资单处理不是员工类的领域。

尽管 SRP 确实要求我从作为现实世界表示的对象转向作为围绕单个功能概念的属性和方法的对象

我基本上想知道有多少人认为在现实世界的代码中使用单一职责原则是合理的，以及有多少人实际这样做了。在Podcast #38中，Joel 谈到这种 OOP 原则在现实世界中是多么无用；并且这进一步证明了像鲍勃叔叔这样的人可能没有编写过非平凡的系统。

我亲自编写过一些软件项目或在一些软件项目中发挥了重要作用，但在我年轻的职业生涯中直到现在才遇到这种模式。我喜欢这个原则的声音，并且真的很想开始使用它。我发现 Joel 在播客中的论点非常薄弱（如果您继续阅读此处的博客评论，其他人也会如此）。但是，这有什么真相吗？

社区是怎么想的？

我有一门课，我一直在添加。

我突然想到这个类不是 Open-Closed，因为所有这些新特性都被添加了。所以我考虑通过将这些函数封装到 Request 对象中来关闭这个类以防止这种变化。我最终得到类似的东西：

这使得 OrderRepository 对扩展开放，对修改关闭。但是，我很快遇到了一些问题：

1.) 请求需要操作的数据是用户提供的（运行时）和依赖注入提供的。我显然不能同时满足一个构造函数。我不能这样做：

并称之为。我想要一种方法让 DI 框架为我“部分地”构造一个对象，然后让我做剩下的事情。但是，我看不到任何这样做的方法。我看到一个博客把这个概念称为“变量构造函数注入”。

2.) 我想到的下一件事是将它分成 2 个单独的类。用户将创建并填充一个 RequestContext，然后将其传递到存储库中，这将创建一个 RequestProcessor（想不出更好的名称）。我想过这样做：

这是一个很好的第一步。但是，请求处理器需要它存储的上下文的确切类型，而我在这里没有。我可以将类型字典用于类型，但这违背了 Open-Closed 的目的。所以我最终不得不做类似的事情：

这很奇怪，我通常不喜欢奇怪重复出现的模板模式。此外，用户填写上下文并要求我提出请求的想法似乎很奇怪，尽管这可能只是一个命名问题。

3.）我想摆脱以上所有，只拥有：

这还不错，但是 API 很丑。现在，这个对象的客户需要“构造”两次，就像以前一样。如果他们忘记调用 PackArgs，我必须抛出某种异常。

我可以继续，但这些是我目前遇到的最令人困惑的问题。有任何想法吗？

我正在使用 ActiveRecord 来维护有关用户的信息。User 类具有预期的 load()、insert()、update() 和 delete() 方法、setter、getter 和其他一些方法。但是我无法决定是否应该将某些其他方法包含在 User 类中，或者由协作者处理。

这是一个例子：

用户可能会请求一些需要确认的交易。这是以传统方式处理的——向用户发送带有链接的电子邮件；点击链接确认用户确实希望交易继续进行。验证密钥的哈希值及其到期日期/时间作为用户记录的一部分保留。

在这个过程中我应该在哪里划清界限？是否应该有一个协作者来处理验证（例如，通过从查询字符串中获取纯文本验证密钥并接受用户对象作为参数）？还是应该由 User 类在内部处理（在方法调用中传递纯文本验证密钥）？

当然，验证后会发生的下一件事是事务将继续进行，需要更新活动记录——在我看来，用户类必须负责。

有什么建议么？

如果我将“数据访问”方法放在业务对象上，我是否违反了单一职责原则 (SRP)？我的直觉是，如果类本身存在 Load 方法，那么 API 会感觉更加用户友好，而不必猜测该方法恰好在哪个类中？

例子：