3

我刚刚在我的 .net 项目中添加了另一个 3rd-party 组件，其中包含一个名为的类Client，它让我想到了常见的类名。

您是否将您的公共课程命名为像 一样常见Client的名称，或者您是否尝试使名称更具体？

过去我会说这很好，Client因为它总是可以通过它的命名Company.Product.Client空间（WebClientTcpClientSmtpClient

我认为 like 的名字MessagePub.Client看起来很整洁，MessagePub.MessagePubClient但更不用说，但是有很多Clients 浮动也感觉很混乱。

我使用的所有这些第 3 方组件实际上都是开源的，因此是否建议重构并将它们的类名更改为更具描述性的名称，以使我的代码更具可读性，或者通过它们的命名空间访问是一个更好的主意？或者它只是无关紧要？:-)

4

7 回答 7

5

我认为一个更具描述性的名字几乎总是更好。它不仅是一个技术问题，而且肯定也是一个语义问题：一方面，它迫使你思考你正在处理什么样的类，并帮助你设定界限。

于 2009-05-24T17:37:32.503 回答
5

当您必须处理使用相似/相同名称的第三方库时，不要忘记命名空间别名量词：

using Excel = Microsoft.Office.Interop.Excel;
using Word = Microsoft.Office.Interop.Word;

像这样，您可以轻松区分不同的类：

Excel.Application excelApp = new Excel.Application();
Word.Application wordApp = new Word.Application();
于 2009-05-24T18:07:00.833 回答
3

如果您的标识符被命名空间消除歧义，那么我无法想象您应该添加更多噪音。就像你说的，感觉很乱。

如果您有可能拥有不止一种，MessagePub.Client例如，只需要消息摘要的，或者是其他接口的消息适配器，那么您当然需要澄清这一点。也许MessagePub.DefaultClient对于常见的情况，MessagePub.DigestClient对于摘要消费者，或者MessagePub.LogAdaptorClient对于消息适配器

于 2009-05-24T17:29:47.537 回答
1

更具描述性的名称是一个更好的主意......因为您将使用以下语句资助某人：

using Company.Product;
using SomeOtherThing.Product;

...如果Client同时出现在两个命名空间中，那么您就会有一些不可读的代码。

常见的对象名称，如Client, Product, User, Person,Message等...我几乎总是会在前缀上加上一些反映其更大目的的标识符。

于 2009-05-24T17:45:17.030 回答
0

好吧，类越具体，它应该有一个更具体的名称 - 考虑到它 DoesNotGetUnnecessaryLongAndUnhandy。

当然，命名空间是区分命名和增加代码解释力的好方法。但是，我不会为了使用不同的命名而重构任何东西。

于 2009-05-24T17:34:36.657 回答
0

您是否将您的公共类命名为与 Client 一样常见的名称，或者您是否尝试使名称更具体？

我尝试做两件事：

  1. 我的任何两个类都没有相同的名称（但我不在乎我的任何类名称是否与第 3 方的名称冲突：这就是名称空间的用途）。

  2. 我的类几乎从不与任何 Microsoft System 类同名（例如，我不会创建一个名为Dictionaryor的类Form）

于 2009-05-24T18:05:49.633 回答
0

客户是一个糟糕的名字，它到底是什么客户？我会说诸如 MailClient、MicrowaveClient、TelephoneClient 等的复合。

于 2011-02-02T12:55:03.380 回答