识别类和类命名策略

Question

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

现在我知道鲍勃叔叔所说的原则，即
避免使用 狡猾的词，例如经理、数据、超级或处理器。 我们应该能够在不使用“if”、“and”、“or”和“but”之类的词的情况下用少于25个词来编写类描述。

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

例如：我有一个场景 1. 我需要向用户发送电子邮件。 2. 用户点击链接时验证邮箱

所以，我的课是这样的：

场景 1：

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

或

场景 2：

class EmailVerifier
    {
          function verifyEmail();
    }

class MailSender
    {
          function verifyEmail();
    }

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

EmailVerifier 类向客户发送电子邮件并验证电子邮件。

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

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

还有，

我有一个场景，我必须，

添加客户、删除客户、编辑客户、保存客户 搜索客户、选择所有客户、按 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 仍然是它自己的类，即发送也是单一职责。