- When you design a package you might decide on the name "Token" for one of your classes. Now, you need the services of a package developed by the display team but they also have a different type with the same "Token" name. When you include the display package into your code you get definitions of the their types you want to use, but also suffer collateral damage by including their ambiguous type name, that you don't intend to use, causing compilation failure. You use namespaces to remove that ambiguity, as long as the namespaces are unique.
-
Namespaces can be nested and so offer the opportunity to provide detailed information about your package design and operation. So,
for example, you might use references in your Project #1, which develops an XML processing facility, that look like this:
PlatformTools::XMLProcessor::Documentto refer to a Document type within your XML Processor package, residing in a group of tools specific for some platform, say Windows or Linux.
- A namespace hierarchy can serve as the basis for organizing your design documentation as chapter and paragraph titles and glossary terms.
Conclusions for Namespace Taxonomy:
All the software within a package must have unique public names, including its references to objects in other packages, otherwise
compilation fails. Additionally public names must be unique over all the code linked into a single execution image or dynamic
link library, otherwise linking fails.
- When you write code in a project with multiple developers you need to use namespaces to insure that names are not ambiguous.
- You make your design easier to understand if you make the namespace names reveal your design intentions.