如何避免抽象类的通用名称？

通常，最好避免将诸如“ handle”或“ process”之类的单词作为例程名称和类名称的一部分，除非您要处理（例如）文件句柄或（例如）unix进程。但是，抽象类通常并不真正知道它们除了处理之外还打算做什么。在当前情况下，我有一个“ EmailProcessor”，它可以登录到用户的收件箱并处理来自该收件箱的消息。尽管我注意到出现了以下样式问题，但我仍然不清楚如何给它一个更精确的名称：

• 更好地将派生类视为客户端，并通过其实现的功能的一部分来命名基类？给它更多的含义，但会违反is-a。例如，EmailAcquirer是一个合理的名称，因为它是为派生类获取的，但是派生类将不会为任何人获取。
• 或只是名字含糊不清，因为谁知道派生类将做什么。但是，“处理器”仍然过于笼统，因为它正在执行许多相关的操作，例如登录和使用IMAP。

摆脱这种困境有什么办法吗？

对于抽象方法，问题更加明显，在抽象方法中，您不能真正回答“这是做什么的”问题。因为答案仅仅是“客户想要的任何东西”。

问题不在于名称，而在于您在一堂课中投入过多。

在您的示例类中，某些部分非常具体（如何获得邮件）。其他部分则非常抽象（您将如何处理邮件）。

最好是使用单独的类，而不要使用继承。

我建议：

• 一个抽象的MessageIterator，由POPMailBoxDownloader子类化

• 另一个拥有POPMailBoxDownloader并处理消息的类。

如果找不到类的好名字，请为该类编写内联代码文档。它以一种气味描述了课堂的目的。通常，我可以从此描述中为该类派上好名字。这对抽象类也很有帮助。

如果类的描述为“登录到用户的收件箱并处理来自它的消息”，则建议使用“ InboxProcessor”作为类名。如果派生类具有“登录用户的收件箱并将垃圾邮件移动到垃圾邮件文件夹”作为描述，我将选择“ InboxSpamMover”作为名称。

使用“处理器”之类的通用名称时，如果它反映了抽象类的通用用途，则不会出现问题。

如果您在用一种或两种香气描述一门课程的目的时遇到问题，那么您可能会遇到设计问题。也许课堂做得太多，违反了“ 单一责任原则”。这也适用于抽象类。

用弗兰克·扎帕（Frank Zappa）来解释，它就是它的名字，应该这样命名。您的示例只是没有深入研究正在进行的处理。是EmailToTroubleTicketProcessoran EmailGrammarCorrector或an EmailSpamDetector吗？

对于抽象方法，问题更加明显，在抽象方法中，您不能真正回答“这是做什么的”问题。因为答案仅仅是“客户想要的任何东西”。

那不是真的。对于抽象的东西您无法回答的问题是“ 它是如何做到的？” 因为那是特定于实现的。如果一个EmailSender类有一个DeliveryStatus deliver(Email e)方法，则有一个隐含的约定，即实现将接收一封电子邮件，尝试传递它，并返回有关其运行方式的某些状态。您不必关心它是连接到SMTP服务器还是将其打印出来绑在归巢的鸽子上，只要实现能够实现所承诺的目标即可。摘要只是量化了承诺，因此实现可以说：“是的，我做到了。”

考虑一下为什么使用这样的单词不好。它们是描述性的吗？那里用什么词来描述课程？EmailBaseClass？比说EmailManager或类似的东西更具描述性吗？关键是要深入了解所讨论的类，因此要找到适当的动词或名词。像对待诗歌一样对待您的代码。