“In many programming languages, namespacing is a technique employed to avoid collisions with other objects or variables in the global namespace. They’re also extremely useful for helping organize blocks of functionality in your application into easily manageable groups that can be uniquely identified.” – Addy Osmani
“A Global Namespace is a heterogeneous, enterprise-wide abstraction of all file information, open to dynamic customization based on user-defined parameters.This becomes of particular importance as multiple network based file systems proliferate within an organization—the challenge becomes one of effective file management.” – wikipedia
O.k, academics aside, in layman terms, the Namespace reffers to the identifiers or names by which you call or access an object. Knowing this, it quickly becomes obvious how important good, descriptive and unique identifiers are. But trotting down the developers path, without a doubt, you – like me, and many others before us – have hit the same wall. Since we all use the same language (predominantly English) and we all model – to some extent – real world interactions into our applications, there are bound to be conflicts with the names we gave our Objects, and similarly named Objects that serve a different purpose.
The problem becomes more apparent and can cause massive havoc when integrating or “plugging in” other people’s bits of code or solutions into our apps.
To better understand this concept and the problem it aims to solve, in as simple a way as possible think of this scenario. You have a John Object. It has data and behavior. John is important and well liked. When you hear the name John, you know exactly what is being talked about.
Some Time later John is integrated in a new wider system. John joins School. Now John interacts with other Objects created by other developers. Since John is such a widely popular and often used name, suddenly a problematic pattern arises. There are other John’s in School. But how can we differentiate them?
Sounds familiar? Then you probably know a real world solution to this problem. As such you decide to wrap your John Object in another Object like so:
Module Smith class John #..... end end
Now, to avoid confusion, when you or other call on John they can do so confidently like so:
Smith::John
Namespacing, at first glance sounds like such a big and complicated deal, and although the issues it solves are of extreme importance, the way it goes about solving them is both simple and elegant. You just add a touch of “specificity” to your Objects so that both you and others can confidently call them, yet not have funky bugs appearing and throwing monkey wrenches in your code.