From DesigningPatterns

Contents 1 Background 2 Scheme I 3 Scheme II 4 Scheme III

Background

Choosing a good namespacing scheme for the company's code is a key decision. Namespaces help to prevent name collisions and also serve as an organizing principle for software. Ruby (via modules), C++ (via namespaces), and Java (via packages) provide language-level support for namespaces, and namespaces can be emulated in older languages by prefixing identifiers. In general, namespaces should be reflected in the file system layout of the code.

Scheme I

In this scheme, each language would have its own namespace root. There would be /usr/lib/c++, /usr/lib/ruby, and /usr/lib/java. Each language directory would have its own namespace hierarchy. One advantage of this is that the standard namespacing scheme for each language is not the same (java's scheme, for instance, has packages named similarly to internet addresses), and this would allow the directory structure for each language to be tailored to the scheme. One disadvantage, however, is that a given project may be comprised of code in more than one language and this scheme would force the code for a given project to be separated into the different language hierarchies. Here is a sample organization tree:

• DesigningPatterns
  • c++
    • Atom
    • Lock
    • Applications
  • ruby
    • Process
    • Applications
      • ProjectCyan
  • java

Scheme II

This is similar to Namespaces#Scheme I, except that only library code (code shared by multiple applications) will be broken up into language hierarchies. All code for a given application will exist in an application specific directory. This is not a perfect solution, however, because some libraries might be shared across multiple languages (with SWIG generating the bindings for each language, for example). Here is a sample organization tree:

• DesigningPatterns
  • Applications
    • ProjectCyan
  • c++
    • Atom
    • Lock
  • ruby
    • Process
  • java

Scheme III

In this scheme the language of a piece of code would have no impact on its namespacing or its file system location. The advantage of this is that similar code in different languages would be colocated, perhaps leading to greater reuse across languages. The disadvantage of this scheme is that it would be more difficult to access and modify all code for a given language. Here is a sample organization tree:

• DesigningPatterns
  • Applications
    • ProjectCyan
  • Atom
  • Lock
  • Process