良好的命名空间命名约定

不管怎样,在我看来都没问题。不过,我会远离缩写,这会让人感到困惑,迫使人们必须知道缩写或查找它们。它们也变得难以阅读和难以形容。

"Lets take a look at the BusObjConfIntContYYYYmmdd package now..."

你可能会遇到的一个问题是名字有细微的差异。由于名字的长度可能是一个问题,你的眼睛可能会忽略整个事情,只看到其中的一部分。这种情况会发生吗?:

BusinessObjects.Incidents.Classifications
BusinessObjects.Classifications.Incidents

BusinessObjects.Forms.ProjectManager.Exportable.Windows.XP
BusinessObjects.Forms.ProductManager.Exportable.Windows.XP

通常,最好不要以实现的任何特定模式命名包,而是以它们所属的业务或功能域命名。

Org.MyCompany.BusinessObjects.Maintenance.Contacts
Org.MyCompany.BusinessObjects.Incidents.Contacts
Org.MyCompany.BusinessObjects.Search.Contacts

相反:

Org.MyCompany.Contacts

我认为这个项目会受益于一点缩写。当我过去遇到这样的问题时,我通常会花一些文档来解释一些用作名称空间的缩写。我通常将这些缩写名称限制为3-5个字符。这不仅增加了表单代码中的一般代码可读性,而且我还发现,较短的名称会减少其他程序员的混淆。

在经历了很多之后,我们试图保持名称空间的数量较低(对于一个非常大的项目,不到几十个),名称空间的深度较短(不到5个左右)。从消费的角度来看(开发人员使用我们的代码库),必须跟踪大量名称空间,其中只有很少的类,这是一种开销,好处很小。

我们还根据使用情况将like和like分组。如果开发人员很可能总是将某些类与其他类结合使用,即使(在您的示例中)一个可能与维护相关,另一个可能不相关,如果它们在逻辑、操作或程序上相关,我们会将它们放在同一个名称空间中。使用提供者模型将独立的功能(例如,特定于维护的逻辑)分解到另一个命名空间中。由于开发人员不太可能需要修改提供程序包含的功能,因此这会进入一个更深入、更独立的名称空间。

您的命名空间层次结构看起来类似于一个称为嵌套泛化的条件。这是当你有派生多种不同方式的类时。

想象一个类层次结构如下:

class Vehicle 

class Car : Vehicle
class CarRed : Car 
class CarBlue : Car 

class Truck : Vehicle 
class TruckRed : Truck 
class TruckBlue : Truck

这个问题在GOF设计模式书中有所描述,特别是Bridge模式。

另外,请参阅这篇MSDN文章,了解命名命名空间的指导方针

命名空间名称: http://msdn.microsoft.com/en-us/library/ms229026.aspx

我为每个库和每个可执行源代码集使用一个命名空间。名字总是很短。例如,在我目前正在处理的可执行文件中,我有:

• Mongo-我的迷你网络服务器库
• DBLite-我的SQLite3包装器;简单
• 几个可执行文件)