solid-principles - 识别类和类命名策略

Question

我正在尝试理解单一职责原则并确定我的系统中可能存在的类。

目前我知道Bob叔叔说的原则，即
避免狡猾的词，如经理、数据、 super 或处理器。我们应该能够在不使用“if”、“and”、“or”和“but”这样的词的情况下用少于 25 个词来写出类的描述。

但是，当我尝试确定我是否真的正确遵循 SRP 时，问题出现了。

例如:我有一个场景1.我需要给用户发邮件。2. 当用户点击链接时，邮箱将被验证

所以，我的类(class)会是这样的:

Scenario 1:

class EmailVerifier
{
      function sendEmail();
      function verifyEmail();
}

或

Scenario 2:

class EmailVerifier
    {
          function verifyEmail();
    }

class MailSender
    {
          function verifyEmail();
    }

如果我说场景 1 是正确的，我试着写下类的描述，就像，

EmailVerifier class sends email to the customer and verifies the email .

如果我说场景 2 是正确的，那么对于我遇到的每个 verb 或每个函数，例如:verifyEmail(),sendEmail(),addEmail()，我需要创建新类。

请告诉我什么是正确的方法。

此外，

我有一个场景，我必须，

Add customer, Delete customer, Edit customer, Save customer Search customer, SelectAll customers, FindCustomer by id

对于这样的类，我可以将它们命名为 CustomerService 类，或者任何其他命名策略会更好。

注意:我已经看过类似的其他问题
Naming Classes - How to avoid calling everything a "<WhatEver>Manager"?

Answer 1

让我们从 Customer 示例开始，因为它更简单。在标准 MVC 架构中，您将拥有一个与 CustomerDAO 交互的 CustomerController。我把它留作练习，供您在必要时搜索术语 MVC 架构 和数据访问对象。

在电子邮件示例中，我们可以通过应用更面向对象的方法而不是过程方法来简化命名问题。简单来说，OOP 告诉我们数据应该与操作它的逻辑相结合。在这种情况下，我建议 Email 对象(数据)应与 verify 函数(逻辑)结合使用，从而允许电子邮件自行验证。

class Email
{
  function verify();
  function getMessage();
  // etc.
}

更好的是，设计模式如 Builder将允许在构造 Email 对象之前进行验证；因为，毕竟，如果不能通过验证，为什么要首先创建一个 Email 对象？请注意，出于与电子邮件对象本身的结构相同的原因，验证逻辑可能会发生变化。更改的相同原因 == 单一职责。

最后，由于发送电子邮件与电子邮件消息本身无关，MailSender 仍然是它自己的类，即发送也是单一职责。