The Namespaces Controversy
Namespaces (or, packages in Java parlance) have been introduced to programming languages in order to reduce (and hopefully eliminate) conflicts. What kind of conflicts, you ask? Well, as the name itself suggests (namespace), we’re talking about naming conflicts.
A classic example could be culled form the core Java API. In the core Java API, we can find two occurrences of the class Date. One is a general Date entity, responsible for handling date-related processing. The other is a more specialized Date, responsible for dealing with date-related stuff as it pertains to Structured Query Language (SQL).
And that’s fine, and that’s how it should be. So where’s the problem, then? The problem arises when we want to use Date in our code. When we say Date today = new Date(); in Java, it is not clear whether we intend to use the general purpose Date, or the Date that specializes in SQL type of processing.
To resolve this ambiguity, creators of Java had introduced packages, or namespaces. Each entity must now belong to a namespace. The ambiguity is thus resolved: the general purpose Date belongs to the java.util package, while the SQL-specific Date belongs to the java.sql package.
This model is then enforced on any Java entity. If you wish to create an Account, you must first specify its namespace. You cannot just introduce an Account, without declaring where does it belong.
The rationale behind this type of reasoning is that now you can have a neatly organized hierarchy. The advantages are easy to see — just look at the following two examples:
accounting.ap.Account
accounting.ar.Account
This arrangement allows us to define both Accounts Payable and Accounts Receivable Account, without having to worry about any ambiguity, or name collision or conflicts.
How Useful is Formal Hierarchy?
This is all great and very exciting if you firmly believe that formal hierarchies are the way to go. But what if we were to cast a bit of a critical eye on this hierarchy business? What’s so great about it to compel us to use it by all means?
As is usually the case in instances when we cannot see clearly, adding a little bit of common-sense can help tremendously. So, if we were to abandon the formalized hierarchical approach and adopt a more common-sense approach, how would it look like?
Basically, instead of saying accounting.ap.Account, we could say:
AccountPayable
That would still ward against name collision, because AccountPayable is different from AccountReceivable (obviously).
Same could apply to the Java core example that we’ve mentioned earlier: instead of saying java.util.Date, we could say DateUtil. And instead of saying java.sql.Date, we could say DateSQL.
Again, there are no name conflicts (there is no possibility of confusing DateUtil with DateSQL).
Sticking with the Common-Sense
Unless there is a very convincing and unavoidable reason to go with a formalized solution, I would advise budding software developers to stick with the common-sense approach. Like the one described above. Think in terms of the human user of your design — what does sound or look more natural:
accounting.ap.Account
or
AccountPayable?