确定 classes 和 class 命名策略

Question

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

目前我知道鲍勃叔叔说的原则，即
避免使用 狡猾的词 ，例如经理、数据、超级或处理器。我们应该能够在不使用 "if"、"and"、"or" 和 "but".

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

例如：我有一个场景 1.我需要给用户发邮件。 2. 当用户点击 link

时，邮箱将被验证

所以，我的 class 会是这样的：

Scenario 1:

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

或

Scenario 2:

class EmailVerifier
    {
          function verifyEmail();
    }

class MailSender
    {
          function verifyEmail();
    }

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

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

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

请告诉我正确的方法。

此外，

我有一个场景，我必须，

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

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

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

Answer 1

让我们从 Customer 示例开始，因为它更简单。在标准 MVC 架构中，您将有一个 CustomerController 与 CustomerDAO 交互。我把它留给你 google 术语 MVC 体系结构 和 数据访问对象 （如有必要）。

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

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

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

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

Identify classes and class naming strategies