Thursday 28 October 2010

How not to namespace (Part 1)

This is always something that bugs me. Consider the following Visual Studio projects:

  • Acme.PetShop.Common
  • Acme.PetShop.Data
  • Acme.PetShop.Services

What is the “Common” suffix for? I don’t see the point (at all). Namespaces are logical groupings, the “common” namespace is “Acme.PetShop”. The Visual Studio projects should be as follows:

  • Acme.PetShop
  • Acme.PetShop.Data
  • Acme.PetShop.Services

“Acme.PetShop” is common to “Acme.PetShop.Data” and “Acme.PetShop.Services”.

There is additional reasoning. For any supporter of the “Acme.PetShop.Common” namespace, I would ask you what is the distinction or rule for putting types in an “Acme.PetShop.Common” namespace and putting types in an “Acme.PetShop” namespace? I am willing to bet you cannot come up with such a distinction or rule. The “Acme.PetShop” namespace always exists by virtue that the “Acme.PetShop.Data” and “Acme.PetShop.Services” namespace exist.

Furthermore, you won’t be able to find a “Common” namespace anywhere in the .NET Framework Base Class Libraries (I have checked).


4 comments:

Unknown said...

Hi Callum

If i can chuck an opinion in here, i think the root cause for this is when people dont have an opportunity to model their domain and components well enough before starting development.

I think people then end up with a situation where they have a class which doesnt logically fit into a component because its a common utility but it might have a data access requirement etc and then they start to worry about the referencing model

i think one of the best advancements in this area is vS 2010 and the ability to constrain the architecture through the diagrams which can be compiled with the code so a well designed structure like you always do cant then be ruined by a lazy developer hacking a class in the easiest place it sort of fits

Callum Hibbert said...

Agreed, common namespaces are fine but my point is that "common" namespaces should not have a ".Common" suffix.

The "common" namespace for "Parent.Child1" and "Parent.Child2" is "Parent" not "Parent.Common".

Callum

Callum Hibbert said...

I should add that when I say there is no "Common" namespace in the .NET Framework Base Class Libraries I mean there is no namespace with the suffix ".Common".

There is a common namespace in the .NET Framework Base Class Libraries, its called "System". See how there is no "System.Common" or "System.Something.Common" namespaces?

Simon Hart said...

I'm with you on this one Callum, 'Common' suffix is for losers.

Common often exists in sub-namespaces too. I have also seen the nameing of "Shared" which is the same as Common within a sub-namespace.

I think this is a legacy hangover from native developers i.e. C/C++ with includes. or Copy books if you code in COBOL.

Simon

About Me