Derived Classes – Understanding Derived Classes and Namespaces

Using static classes as namespaces defies the purpose of having namespaces.

The key difference is here:

If you define CategoryA, CategoryB< as namespaces, and when application uses two namespaces :

CategoryA::Item1 item = new CategoryA::Item1(); 
CategoryB::Item1 item = new CategoryB::Item1();

Here if the CategoryA or CategoryB is a static class rather than namespace, the usage for the application is almost same as described above.

However, if you define it as a namespace and application uses only 1 namespace (doesn't include CategoryB), in that case application can actually use following

using namespace CategoryA; 
Item1 item = new Item1(); 

But had you define CategoryA as a static class the above is undefined! One is forced to write CategoryA.something every time.

Namespaces should be used to avoid naming conflicts whereas class hierarchy should be used when class grouping has some relevance to the system model.

Personally, I like this approach, because:

• It is a way to standardize class type definitions. If you want you can see it as a kind of interface definition for types to be used for template instantiation, because you cannot instantiate this template with arbitrary types (for 'TypeOfData' type variable). Instead, a concrete 'TypeOfData' must define an inner 'In' and an 'Out' type definition.

• You avoid writing a template which needs three type variables (in this concrete case) -- something like

  template <class TypeOfData, class TypeOfIn, class TypeOfOut>
  class Codec
  {
  private:
      TypeOfIn* reader;
      TypeOfOut* writer;
  };
  

  which makes instantiating this template more complex. Also, you can pass any types for 'TypeOfIn' and 'TypeOfOut'. While this is more generic, it might not be the intention of the template's author. In this concrete case you can see, that there must be exactly one 'In' and one 'Out' type associated with a class 'TypeOfData', which is defined by 'TypeOfData' itself. Using a template with three type variables wouldn't tell you anything about these constraints. Furthermore, the template instantiator (client code) would have to know what 'TypeOfIn' and 'TypeOfOut' he had to use with a class 'TypeOfData'. And this will cause problems if, sometime in the future, the associated 'TypeOfIn' and 'TypeOfOut' types to be used with 'TypeOfData' change. Using the OP's version, client code would likely not have to change, because the template gets the correct types to use from 'TypeOfData' and not by client code.

So I think using this approach is good if these arguments match your requirements. BTW, in that case I wouldn't mind being forced "to :: my way to static method" (or type definitions). If they don't, however, you might be better off using another approach and profit from a possibly more generic (template) solution.