Class 单一责任原则和类别
我希望我能弄清楚我在挣扎什么：-）开始了。 我想知道如何在以下情况下实施SRP： 有一个项目。完成后，必须给联系人邮寄一份调查报告，让他对项目进展情况给出反馈 该软件有一个项目类。有一个过程可以循环所有项目。 我已经分离了所有用于发送到名为ContactMailer的类的代码，该类将项目作为参数，类似于ContactMailer.AttempMail（project） 但在某些情况下不发送邮件：项目标记为DoNotSurvey，或标记为Challenged（=有人质疑不应发送邮件，管理员必须对此作出决定），以及此类项目是否没有有效的调查 我的问题是：这个检查可以在像CheckMailConditions之类的过程中进行，但是这个过程属于哪里呢？它应该在de ContactMailer中吗？虽然这是一个检查邮件是否应该发送的检查，但感觉有点不对劲。还是应该单独上课？这听起来像是SRP（一个只有一个职责：检查条件的类），但这会导致一个类只有一个方法，这似乎有些过分 或者我应该在调用ContactMailer.AttempMail之前检查这些条件，因为它们是项目的属性？我有点迷路了Class 单一责任原则和类别,class,oop,conditional-statements,single-responsibility-principle,Class,Oop,Conditional Statements,Single Responsibility Principle,我希望我能弄清楚我在挣扎什么：-）开始了。 我想知道如何在以下情况下实施SRP： 有一个项目。完成后，必须给联系人邮寄一份调查报告，让他对项目进展情况给出反馈 该软件有一个项目类。有一个过程可以循环所有项目。 我已经分离了所有用于发送到名为ContactMailer的类的代码，该类将项目作为参数，类似于ContactMailer.AttempMail（project） 但在某些情况下不发送邮件：项目标记为DoNotSurvey，或标记为Challenged（=有人质疑不应发送邮件，管理员必须对此
提前感谢您的想法 我不认为你在你的
ContactMailer顺便提一下，如果您将检查逻辑分离到一个单独的类中，您会将该类称为什么<代码>MailConditionsChecker？根据我的经验，如果很难想出一个合理的名词来命名你的班级，这通常是一个坏兆头 谢谢你的反馈，这有助于我更确定该做什么选择。关于命名困难的经验法则，我会记住：）你建议的名字听起来像是我会使用的名字。出于好奇，您提到的将检查逻辑抽象到类中的好理由是什么？我想到的一个原因是，如果有很多条件会使代码变得混乱-但是你也可以把它放在一个过程中。我可以想到几个原因来将它分离出来-也许另一个类需要能够共享相同的检查逻辑。或者，您可能需要能够在某些环境/情况下运行mail类，而无需检查逻辑，可能是在测试时。顺便说一句，欢迎使用stackoverflow！如果答案对您有用，请记住单击绿色箭头接受它。谢谢