单一责任原则和课

我希望我能说清楚我正在努力:-)在这里。我想知道如何在以下情况下实施SRP：单一责任原则和课

有一个项目。完成后，联系人必须邮寄一份调查问卷，并在其中提供有关项目进展情况的反馈。

该软件有一个项目级。有一个循环遍历所有项目的过程。我已将所有用于邮寄的代码分离到名为ContactMailer的类中，该类将项目作为参数，如ContactMailer.AttemptMail（project）;

但是在某些情况下邮件不会被发送：项目被标记为DoNotSurvey或标记为Challenged（=有人对是否发送邮件不应该发送邮件以及管理员必须做出决定）发生争议，以及如果这种项目没有有效的调查。

我的问题是：这个检查可能在CheckMailConditions之类的程序中，但是这个程序属于哪里？它应该在ContactMailer中吗？虽然这是一个检查，如果应该发送邮件，这感觉有点关闭。还是应该是一个单独的课程？这听起来像SRP（一个有责任的类：检查条件），但这会导致一个类有一个方法，这看起来有点过分。

或者我应该在调用ContactMailer.AttemptMail之前检查这些条件，因为它们是项目的属性？我有点迷路。

在此先感谢您的想法！

来源

2013-08-07 Sebastiaan.Everyman

我不认为你通过在你的ContactMailer类中包含检查来打破单一职责规则。如果项目符合某些条件，它将有发送邮件的单一责任。

一个具有单一方法的类不一定是矫枉过正的，并且可能有很好的理由将检查逻辑抽象为一个单独的类，这对我而言并不明显。但是，从你所说的话来看，我认为你的架构听起来绝对没问题。

就像旁边一样，如果你确实将检查逻辑分成了一个单独的类，那么你会怎么称呼这个类呢？ MailConditionsChecker？根据我的经验，如果难以想出一个明智的名词来命名你的班级，这通常是一个不好的迹象。

来源

2013-08-07 23:49:21

感谢您的反馈，这有助于我更确定要做出选择。有关命名困难的良好经验法则，我会牢记在心:)您的建议名称听起来像我会使用的名称。出于好奇，如上所述，将检查逻辑抽象为类是什么原因？想到的一个原因是，如果有很多条件会使代码变得混乱 - 但你也可以把它放在一个程序中。 –

我可以考虑将其分离出来的几个原因 - 也许另一个类需要能够共享相同的检查逻辑。或者也许你需要能够在某些环境/情况下运行邮件类而不用检查逻辑，或许在测试时。 –

顺便说一句，欢迎来到stackoverflow！如果答案对您有用，请记得点击绿色箭头接受它。谢谢。 –

单一责任原则和课

回答

相关问题