Reputation: 59
Pros & Cons with both approaches?
Approach-1: using namespace
namespace inner{
class MyInnerClass
{
public:
MyInnerClass();
virtual ~MyInnerClass();
};
};
#include "MyInnerClass.h"
namespace inner
{
MyInnerClass::MyInnerClass()
{
}
MyInnerClass::~MyInnerClass()
{
}
}
#include "MyInnerClass.h"
namespace inner{
class MyInnerClass;
};
class MyOuterClass
{
public:
MyOuterClass();
virtual ~MyOuterClass();
private:
inner::MyInnerClass* ptrMyInnerClass;
};
#include "MyOuterClass.h"
MyOuterClass::MyOuterClass()
{
ptrMyInnerClass= new inner::MyInnerClass();
}
MyOuterClass::~MyOuterClass()
{
}
Approach-2: implementing as real inner classes
class MyOuterClass
{
/* Inner Class */
public:
class MyInnerClass
{
public:
MyInnerClass() {}
virtual ~MyInnerClass() {}
};
public:
MyOuterClass();
virtual ~MyOuterClass();
private:
MyInnerClass* ptrMyInnerClass;
};
Upvotes: 3
Views: 267
Reputation: 29970
I only know one advantage of the namespace scheme. With namespaces, you can forward declare classes, while you cannot do the same with inner classes, if the outer class definition is not available. So, with namespaces, you can do this:
namespace Outer {
class Inner;
}
However, you cannot do the same with inner classes, if definition of Outer
is not available:
class Outer; // we forward declare Outer
class Outer::Inner; // this doesn't compile
In the same manner, you cannot define Outer::Inner
without the definition of Outer
.
Because of this I almost never use inner classes (I only use small inner class, when I'm 100% sure the forward declaration is not needed, which is usually the case when the inner class is not public).
Note, there is a 3rd solution, which I usually use: I name "inner" class as something like OuterInner
.
For example, if you have an outer class named SomeManager
, and you would have a public inner class named Node
, I'd use class SomeManagerNode
:
class SomeManager;
class SomeManagerNode;
The only difference I know about this method is that SomeManagerNode
cannot access non-public members of SomeManager
(If Node
was an inner class to SomeManager
, it could access all members of it). But this can be desirable in certain situations, so it is not a real drawback. But if the access is needed, you can declare SomeManagerNode
as a friend
of SomeManager
.
The only reason to use inner classes is when the inner class is a private implementation detail, which is not used anywhere outside the class.
Upvotes: 2
Reputation: 5166
In larger projects, otherwise will be handicapped, similar objects or classes are categorized into corresponding namespaces for ease of refactoring and readability.
Normally, an object which will be intrinsic to another object only and rarely going to be used otherwise is declared as private inner class. By doing so, the intent is made clearer as the implementation is hidden and the inner object is not exposed.
Upvotes: 2