良好的命名空间命名约定

不管怎样,我觉得还可以。我会远离缩略语,这会让人困惑,迫使人们必须知道缩略语或查找它们。同时,它们也变得无法阅读和无法形容。

"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

其中包含类/接口/对象/对“联系人”执行操作的任何内容。

我希望这有帮助。归根结底,这真的取决于你的团队的偏好。。。

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

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

设想一个类层次结构,如下所示:

class Vehicle 

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

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

GOF设计模式书中描述了这个问题——特别是桥接模式。

另请参阅这篇MSDN文章,了解命名名称空间的指导原则

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

• ALib-我的通用工具库
• Mongo-我的迷你web服务器库
• 持久层
• 两个可执行文件)

这似乎很有效。我发现应该避免使用非常复杂的名称空间方案,就像非常复杂的深层类继承人体系结构一样。