我正在读《清洁代码》这本书http://www.amazon.com/clean-code-handbook-software-techniship/dp/0132350882

作者提到，您应该避免使用类名中的诸如manager、processor、data或info之类的词。我到处都用过这些。什么是更好的名字？我有一个类负责启动和停止连接。所以我把它命名为ConnectionManager。

等待！

书中的要点是，类名中的管理器意味着类做了不止一件事。罗伯特·C·马丁在本节中提到了单一责任原则！

这与名称无关，它与通常这样命名的类有关。更改名称不会减少类的责任！

我猜这本书之所以这么说是因为它试图鼓励你为你的班级选择一个更具描述性的名字。这里没有"命名约定"，这是您首先遇到的问题。任何通用命名约定都无法考虑特定类并为其选择最佳名称。表达性比遵循命名约定更重要。称一个类为"管理者"或"处理器"并不能说明它对第一次阅读代码的人有什么作用。

如果您真的想不出更好的方法，那么命名一个类ConnectionManager并没有本质上的错误。但我至少要用它所管理的集合的类型来命名它。或者它是如何管理这些集合的。或者为什么它管理这些集合。

还要考虑到，遵循"一刀切"的规则很少能帮助任何人编写更好的代码(至少，在"更易于理解"或"更具表现力"的意义上，这并不是更好)。我倾向于用Manager来后缀所有本地包装类的名称。例如，我可能有名为DwmManager或VisualStylesManager的类。在那个非常具体的案例中，它对我确实有意义。如果在我的代码库中看到一个名为Manager的类，我知道它包含了一系列密切相关的功能。你必须根据具体情况来做决定，理解你最终想要达到的目标。

如果您完整地阅读了代码，并且遗漏了有关编写清晰易懂(因而可维护)的代码部分，那么您可能遗漏了要点。

在ConnectionManager类的示例中，该类可能更表示需要"坏"名称的设计缺陷。除了执行在名为mydatabaseconnection的单例子类中同样容易执行的操作外，类是否还执行其他操作？

以名称dataprocessor为例。

首先，每个函数处理数据、获取数据或返回一些数据是正确的，除非

但如果它是这种类型的函数，那么它绝对可以制造出某种东西，所以在任何情况下，它都是处理器。

数据处理器基本上是任何东西，因为它没有说明它的操作方式。所以你应该更换

例如，带有用户信息存储的数据处理器。

"helper"、"common"、"core"、"utilities"似乎等于或最差于"manager"。他们对自己的所作所为一言不发。"工厂"在这里是绝对错误的。备选名称为"协调人"或"控制人"。

yous said: I have a class that is responsible for starting and stopping connections. So I named it ConnectionManager.

如果类只是"启动"和"停止"连接，为什么不"ConnectionSwitcher"？

you said: I have used these everywhere.

我也有很多经理课程。今天我决定改名为"会计经理"。它使用帐户存储库来执行CRUD操作。

我把它分为"accountsecurity"和"accountoperations"。

它们存在于myproject.businesslogic命名空间中，并且都使用公开CRUD方法的AccountRepository类。前者负责"登录"和"更改密码"等操作。后者负责对数据库执行CRUD操作，但受某些逻辑的控制，例如，如果帐户存在某些注册表记录，则无法删除该记录。(AccountOperations也使用其他存储库来检索所需的信息)

我对"操作"不满意，我正在寻找更好的东西(协调员、主管……)，但这是一个开始。

我的案例就是这样思考的一个例子。

哦，不！！

请不要被关于如何"应该"命名事物的一般性声明所吓倒。毕竟它们是你的东西。也许你的名字"manager"比"connection manager"好，因为它比较短。尤其是如果代码的这一部分主要管理"连接"，而其他的很少。

我相信这样的书有非常有用的想法，但只为永远不会读它们的编码员。为什么？因为读过这些书的工程师们已经内化并将最合理的原则融入其中。不愿意阅读的编码员也不在乎。

我经常使用"初始化"或"初始值设定项"。如果是其他的，我通常会想到一个与我想到的第一件事相比非常长的同义词。我还使用术语"解析器"和其他东西。

不要太在意这个名字，不要太在意它，除非你或某人真的不喜欢它。