C++ Is it okay to use nested classes as a way to namespace derived classes?

Question

I have many abstract classes that describe many abstract ideas and objects. These classes have many complex relationships with each other, and I realize that while writing code with some of the derived classes can get confusing. For example, it isn't completely clear at first glance if class C is derived from class A, or if it derives from class B.

This is just an example and doesn't relate to the actual application:

These four classes describe 4 different types of vehicles,

• Ground

• Air

• Water

• Space

Now I'm hoping to declaring my derived classes inside the base class so I can specify the class by doing this:

class Ground {
    class HondaAccord;
}

// Now I know that HondaAccord is for certain a ground vehicle
Ground::HondaAccord car();

While for something as simple as this it's not really worth the increased clutter, In my opinion it makes it clearer and explicit in my specific codebase. Plus I could declare the derived classes here and defining the functions elsewhere so I wouldn't need to import a HondaAccord.h or anything when using the HondaAccord class.

It is my understanding that the nested class is effectively the same as a normal class. I was hoping to get more information from more experienced people to understand if there are potential issues down the line that I'm not seeing.

Thanks

Answer 1

This is a very bad idea, because it breaks the Open/Closed Principle:

• Classes should be open for extension, but closed for modification. This means that it should be easy to "extend" your abstract classes (e.g. Ground) via inheritance, without modifying them.

• Unfortunately, your nesting strategy would force you to modify your abstract class for every new specialisation that you add (e.g. HondaAccord)

If you want a namespace, simply use C++ namespace: they are designed for this purpose and provides features that make naming and nesting easy and practical.

Answer 2

C++ supports nested classes, so from a purely syntactically point of view, you might do this.

Not having to write #include HondaAccord.h can be achieved by bundling includes in one one header file also for non-nested classes, so this is no valid argument.

If you are fine that this forces one to write Ground::HondaAccord instead if HondaAccord, or Gameobject::Ship instead of Ship is somewhat opinionated and depends on the context. If the codebase will end up with a lot of snippets like Ground::HondaAccord or Ground::VWPassat or Ground::Fiat500, then this might become tedious. Of course, may have use some typedef to avoid frequent repetition of the base class name. If this code only appears only inside some factory, however, then it probably won't matter much if you nest the classes or not.

Imagine you note afterwards that Ground was a misleading name, and it should have been GroundVehicle instead. Are you ok to change this whereever it occurs in the code? It might also depend on your refactoring tools, the total resulting length of the real names, and the necessity to repeat the information that HondaAccord, VWPassat and Fiat500 are ground vehicles (which might also be seen as superfluous).

TLDR; it can be ok or not - it depends.

Answer 3

Plus I could declare the derived classes here and defining the functions elsewhere so I wouldn't need to import a HondaAccord.h or anything when using the HondaAccord class.

The example you've shown is just a declaration of HondaAccord, if you include only that header the type HondaAccord is incomplete, so you are hiding that it is derived from Ground. Your example doesn't work, because you can't instantiate an object of incomplete type.

It is my understanding that the nested class is effectively the same as a normal class.

Whilst a class's definition is a namespace, it's more common to use an actual namespace for that purpose.