naming-conventions - 有没有最好的方法来处理命名时尚？

Question

在去年和我团队代码库的一些工作中，我注意到命名约定的稳步发展。

例如，有很多类被命名来表示它们是一个可以帮助你做某事的类。

这是我发现的:

MyClassUtil
MyClassFactory
MyClassHelper
MyClassManager
MyClassService

在我看来，随着时间的推移，人们会为相对相同的事物提出命名约定，因此不是以一致的方式命名所有内容，而是最终得到一个包含一些约定的代码库。所有新东西都是根据最新的时尚命名约定命名的，因此您几乎可以通过当时流行的约定来判断一段代码的时代。

处理这种趋势的最佳方法是什么？真的有问题吗？随着这些命名时尚的流行，人们应该使用最新的时尚吗？是否应该使用新的命名约定重命名所有现有项目？还是应该接受这种多样性是不可避免的？

Answer 1

它们看起来不像是时尚……所有这些名字都暗示了类(class)的目的，而这些目的是不同的。对于编程，一切都在名称中，应该非常谨慎地选择它们。品种不需要逃避。名称不同，因为类的目的不同。

MyClassUtil
- 一些与 MyClass 一起工作的实用程序，但它没有附带。也许 MyClass 属于您正在使用的库，但您经常使用一些更高级别的函数，并且您需要在某个地方放置它们。

MyClassFactory
- 以抽象的方式创建 MyClass 的实例。这允许您编写需要 MyClass 实例的代码。它可以从 MyClassFactory 中获取这些新实例。这将允许工厂在 future 进行修改以提供 MyClass 的不同特定实现。也许在单元测试下，工厂只是提供虚拟/模拟 MyClasses。这意味着可以测试使用工厂的类而无需更改它，只需更改工厂，然后您就可以隔离正在测试的类。

MyClassHelper
-好吧，我可能同意，也许这可以更具体。它对 MyClass 有帮助，但又是什么。也许这有点类似于 MyClassUtil。但是，可能 MyClassUtil 是与 MyClass 一起使用的通用函数，而帮助程序使用 MyClass 的特定实例进行初始化，然后可以对该实例执行操作。你需要为每个你想帮助的 MyClass 提供一个新的助手。

我的类(class)经理
- 也许这处理 MyClass 实例池并存储或编排它们。例如。在 CommunicationsManager 中，该类将处理连接在一起的类，这些类处理与以太网或串行等端口或连接的通信，以及一个处理通过它发送的通信协议(protocol)以便它可以传输数据包的类，以及一个处理这些数据包中的消息。

我的类(class)服务
- 服务可以为您做事，例如给定邮政编码将其转换为网格引用。通常一个服务可以解决很多具体的事情。对于邮政编码示例，此类可能具有可以与不同网站对话以进行转换的实现。