When to use nested classes and when to use namespaces

c++11classnamespace

I have really never made use of namespaces, and am considering them at the moment.

My situation. I have a class Reverb. It contains as members instances of other classes, declared in the same header file, above it. Now there are appearing more and more data structures, relevant to the Reverb class e.g. 3 different representations of the user settings.

So I made a class Settings, that contains 3 sub-classes for the 3 representations and some methods to convert between them.

My question is where to place that?

Put it inside Reverb? Then the Reverb API becomes quite bloated and scroll-heavy.
Put it in file scope? Any user of the header will be unpleasantly surprised to find a class Settings, that actually means ReverbSettings.
Create a namespace Reverb and put everything in it? Then what to do with the class Reverb? It would be strange to ask for Reverb::Reverb.
Any better solution?

Best Answer

The questions to ask are can a nested class exist without its enclosing class? Does a nested class need intimate visibility into its enclosing class?

I tend to avoid nested classes in general because of the tight coupling. I would rather refactor the nested class to its own top-level class and use interfaces/pure virtual base classes to give it a reference to what used to be its enclosing class. Often what I find is I can have smaller classes that are more laser-focused on a single task and are reusable.

In C++ you also have the friend keyword which can provide visibility into class internals. While it should be used sparingly, it is useful for those cases where two classes need to work closely together but do not represent quite the same abstraction.

Short version: there is nothing wrong with nesting classes, but prefer namespaces. In rare cases where it is warranted, friend can also be used.

Related Solutions

Derived Classes – Understanding Derived Classes and Namespaces

It should be in the namespace of your application

Since you are extending the class to add features for your application, the class should be part of your application's namespace, not a different one.

Now if other applications would also be using this derived class in addition to your 1st one, then I would make a separate library file (and namespace) which contains any customized components from the first namespace, and import this library into any application that needs to use the derived class.

C++ Scope – Nested Classes vs Namespaces

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.

Best Answer

Related Solutions

Derived Classes – Understanding Derived Classes and Namespaces

C++ Scope – Nested Classes vs Namespaces

Related Topic