Namespaces

Alex Bunardzic has written an interesting article about namespaces. He calls into question the usefulness of the canonical approach of hierarchically structured namespaces. I think he’s onto something but his example are pretty weak. It is easy to pick on the Java package names because they are often over the top. Unfortunately, Java package names are the namespaces that are most familiar. Most of the weirdness of Java package names come the fact that they tend to be used as way to categorized entities1. Using namespaces as a categorization mechanism is misguided and generally results in package names that are both bad namespaces and bad categories.

The primary use of namespaces is name disambiguation. This is a vital feature of programming languages. Any language without integrated namespace support has a gaping hole. Name disambiguation is provided by allowing a name in particular namespace and that same name in another namespace to co-exist simultaneously and independently .

Name disambiguation is necessary when multiple implementations of the same logical class exist. Name disambiguation is rarely required within the application layer. Developers generally have enough visibility into their own code base to avoid implementing duplicate classes. When naming conflicts occur it is usually between two independent libraries or between the application and the libraries it uses.

Namespaces should be used exclusively to prevent name conflicts. Class names should always include enough information so that a reasonably information person will know the purpose of the class. This means if you have an accounts payable object it is called “AccountPayable” regardless of what namespace in which it lives.

Name conflicts are a real issue. Code that will be used in an unknown environment should be in a non-default namespace. That means if you are writing a reusable library it should should have it’s own namespace. Namespaces should usually match independently installable components. Any namespace that you can only get by installing some other package probably should not exist.2

Just to be clear, namespaces are pure overhead. They are necessary in many situations but namespaces add no value to the application. One way to minimize the overhead is to put your application classes in the default (or null or root or whatever your language calls it) namespace. That means that the classes that you spend most of your time using do not require any namespace overhead. You will be responsible for ensuring that your code base does not include multiple classes with the same name. That is a constraint you should embrace because having multiple classes with the same name is just confusing.


  1. I use the word entity because in Java the things you name are not really objects.

  2. An interesting effect of this is that in a system with installation type packaging built in at the core you could treat namespaces as a aspect of the package management system. I wonder if you could retrofit that on top of RubyGems such that loading a gem resulted in all the classes being contained in a module with the same name as the gem?

4 thoughts on “Namespaces

  1. Is it thus your proposition that the separation of concerns via packages — ie for the sake of Good Design(tm) — should use some other mechanism besides namespaces?

    Simon

  2. Simon,

    Yes, I do propose that namespaces should not be relied on for
    separation of concerns. Objects are the appropriate level at which to
    manage cohesion and encapsulation, not packages. I think that
    namespaces should be used to avoid name conflicts. Period. If you
    need categorization or access control or whatever some mechanisms
    other than namespaces should be employed

  3. Wow! That strikes me as a really odd perspective.

    I have some empathy for the idea that sometimes package structures are hard to, or sub-optimally, categorized. But I find the use of namespaces to categorize design components very beneficial for promoting good design, as well as making high level design more obvious. Where such heirarchies break down is when you logically have multple inheritance.

    A long time ago I had a job coding in TOOL, which was Forte’s language. Its inclusion mechanism was stricly at the package level. And circular dependencies were not allowed. It was interesting coding with that restriction. I forced you into good design. (However, you’d probably be about as happy with that as you are with static typing. And there are times when strictly “pure” design is too much of a pain to be cost effective.)

  4. Mike,

    I think the problem with using namespaces for categorization is that
    things invariably belong in multiple orthogonal categories.
    Hierarchical categorization structures are too limited which is why
    tagging is all the rage lately. And to make things worse, encoding the
    categorization into the name of a entity means that you can never
    easily change your mind about how that entity should be categorized.

    I think that a sophisticated categorization mechanism could be very
    useful. I just do not the namespaces are the right mechanism. I
    would be very interested in a system that allowed tag style
    categorization of classes. If tagging a class was cheap I think it
    would make most systems significantly easier to work with. I am not
    sure how well that would work in a text file based system, though.
    The effort of checking in a file each time you added a tag might raise
    the cost of tagging too high.

Comments are closed.