Good Namespace Naming Conventions

Question

I am creating a class library for a CRUD business application. The major "categories" of business objects (with related data access layer objects) are:

• Maintenance (for working with master tables (master lists) in the database
• Incidents (most objects relate to a real-world incident)
• Search (obvious)

As of now, my namespaces are set up as follows:

• BusinessObjects.Maintenance.Contacts
• BusinessObjects.Maintenance.Products
• BusinessObjects.Maintenance.Classifications
• .
• BusinessObjects.Incidents.Contacts
• BusinessObjects.Incidents.Products
• BusinessObjects.Incidents.Classifications
• .
• BusinessObjects.Search.Contacts
• BusinessObjects.Search.Products
• BusinessObjects.Search.Classifications
• .
• Dal.Maintenance.Contacts
• Dal.Maintenance.Products
• Dal.Maintenance.Classifications
• .
• Dal.Incidents.Contacts
• Dal.Incidents.Products
• Dal.Incidents.Classifications
• .
• Dal.Search.Contacts
• Dal.Search.Products

Notice that every class ends up with the same name.

Is this good form?

Are there any issues that can arise from this namespace convention? Any possible confusion to another person looking/using this code?

I do realize that in the form code, one drawback will be that I will have to qualify all objects with the namespace. To me, that isn't a big deal. I usually prefer a little explicit-ity, if that's a word.

Answer 1

I think the project would benefit from a bit of abbreviation. When I've encountered problems like this in the past, I typically devote a bit of documentation to explaining a few abbreviations that serve as the namespaces. I usually restrict these shortened names to 3-5 characters. Not only does that add to general code readability in the form code, but I've also found that the shorter names lead to less confusion from other coders.

I hope that helps. At the end of the day, it really just depends on your team's preferences...

Answer 2

It seems Ok to me anyway. I would stay away from abbreviations though, that would get confusing and force people to have to know the abbreviations or look them up. Also they become unreadable and unspeakable.

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

One issue you might run into is names with subtle differences. With length of names being a possible issue, your eyes might gloss over the whole thing and pick up only part of it. Would there ever be a case where this happened?:

BusinessObjects.Incidents.Classifications
BusinessObjects.Classifications.Incidents

or

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

That contrived example might become a problem.

Answer 3

After going through this a lot, we try to keep the number of namespaces low (less than a few dozen for a very large project), and the depth of the namespaces short (less than 5 or so). From a consumption standpoint (developers using our codebase), it is an overhead with very little benefit to have to keep track of a large number of namespaces with few classes in them.

We also group like with like, based on usage. If a developer is fairly likely to always use certain classes in conjunction with others, even though (in your example) one may be related to Maintenance and the other not, if they are logically, operationally or procedurally related we put them in the same namespace. The functionality that is separate (for example, maintenance-specific logic) is broken into another namespace using a provider model. Since a developer is less likely to need to modify the provider-contained functionality, that goes in a deeper, separate namespace.

Answer 4

I use one namespace per library and one per executable source code set. The names are always short. For example, in the executable I'm currently working on, I have:

• ALib - my general utility library
• Mongo - my mini web server library
• DBLite - my SQLite3 wrapper & simple persistence layer
• Track1 - executable (actually a couple of executables)

This seems to work pretty well. I find that very complex namespace schemes should be avoided, in the same way that very complex, deep class heirarchies should.

Answer 5

Your namespace hierarchy looks similar to a condition called nested generalization. This is when you have classes which derive multiple different ways.

Imagine a class hierarchy as follows:

class Vehicle 

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

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

Note that vehicles can be either cars or trucks. Also, vehicles can be either red or blue. This works perfectly well, but there is a problem when you want to add a new color, or vehicle type, because the burden of modification grows quadratically.

This problem is described by the GOF design patterns book -- Specifically the Bridge pattern.

Although it doesn't specifically address the concerns about namespaces, my instinct tells me that the situations are similar. I would say, if you can avoid this, then you should.

Answer 6

It's generally a good idea to not name your packages after any specific pattern implemented but rather the business or functional domain they belong to.

ie:

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

instead:

Org.MyCompany.Contacts

which would contain classes/interfaces/objects/whatever that perform operations on "Contacts".