对变量/类/组件名称使用过于特定的名称是好的还是坏的做法？

Question

假设我们有一个系统，在这个系统中，用户可以相互聊天，并且我们正在后台工作。

我们可以将获取聊天的服务命名为以下方式之一：

ChatsService
UserChatsService

如果我们使用第二个版本，这是一个不好的做法，还是它是好的，在你的意见？这种方法可以在任何地方重复，也可以在变量名称中重复。

保存该服务的变量将被命名为userChatsService，等等。另一个变量可以称为userPhotosService等，而不仅仅是photosService。

此外，文件夹结构遵循这样的约定，如Services/Users/UsersChatService

这种过度指定变量名的方式是为了允许以后扩展系统，即使现在没有关于这个扩展的信息。(商户之间的聊天系统可能会晚些时候来)。

这种思维方式是一种过早的优化，还是过于乐观的思维，还是一种良好的实践？

Answer 1

我要用一种稍微不同的方式来处理这个问题:这不重要。

这个问题的关键不应该是我们如何命名事物。相反，当需要重新命名时，我们需要关注所产生的成本，因为，正如许多人已经指出的，将来验证应用程序是浪费时间。请记住，应用程序设计的质量最好是通过评估随着业务规则的发展和流程的发展而进行更改的难度来理解的。

考虑到以上情况，我们可以看到，这确实是一个关于商业价值的问题。是否存在花费时间试图标准化特定命名约定所产生的业务价值？有可能。只要我们把注意力集中在重要的事情上。也就是说，应用程序的公共面(类型、接口、方法)。

例如，要求开发人员命名包含UserChatService对象userChatService的变量并不会增加业务值，因为不能在变量名称上创建依赖项。事实上，这样的规则会使将UserChatSerice重构为ChatService更加痛苦，因为需要重命名本地作用域变量。

因此，下一个问题是，对应用程序的公共表面有严格的命名约定会产生多少业务价值？现在，IDE的make重构是一个非常无痛的过程，因此，除非重构类名(部署、分发等)会产生附带影响，否则我不确定这样的约定是否真的会增加多少价值。

最大的价值是通过与应用程序的发布面有关的约定来增加的。方便地说，公约已经存在(例如REST)。把注意力放在这上面。

Answer 2

在一个只有一个这类服务的系统中，ChatsService显然是足够清晰的。如果您稍后将获得用户聊天服务和商家聊天服务，请相应地重命名这些类以明确显示。理想情况下，您的环境支持自动重命名，这使得这很容易。

当然，有时以后重命名类并不那么简单，因为它们成为可重用库或数据库模式的固定API的一部分。在这种情况下，如果您真的希望得到一个UserChatsService和一个MerchantChatsService，那么最好尝试尽可能地提前计划。

Answer 3

计算机科学中只有两大难题:缓存失效和命名( 菲尔·卡尔顿 )

你投资于一个名字的设计资本的数量取决于它的可见度。在选择名称时，实现语言会给您很大的自由，这是相当常见的，选择合适的拼写是一个惯例问题。私人的事情不需要太多的投资，因为改变的成本很小。另一方面，已发布名称的更改成本很高。

凯夫林·亨尼( Kevlin )至少拥有专注于人名的一次谈话 (幻灯片)

UserChatsService是一种糟糕的实践，因为使用这个世界的“用户”表明，您并没有在用例上投入太多的精力(我们期望一个人在某个地方参与到聊天中，并且不会费心把它缩小到70亿人以上)。

将角色的名称与实现的名称分离是相当常见的--比如List与ArrayList或LinkedList。

这种想法是过早的优化吗？

预测是很困难的，尤其是关于未来的；为你现在所拥有的东西而专注于一个好的名字可能比把注意力集中在一个你以后可能没有的东西的名字上要好。

也就是说，遵循本地习惯有其自身的优点，即使本地习俗不是最优的。