Using nested classes to modularize large application code?

Question

I'm building a large Desktop application, which will have a range of functionality, for each I wish to have a specific class.

I'm thinking of using a nested class structure to modularize the code and ensure separation of interface vs implementation:

class Manager
{
 public:
 Manager(); //Initialise *t and *wapi in constructor
 ~Manager(); //Delete *t and *wapi in destructor
 private:
 class Transport;
 Transport *t;
 class WinAPI;
 WinAPI *wapi;
};
class Manager::Transport
{
 public:
 Transport(); //Initialise *tcp and *http in constructor
 ~Transport(); //Delete *tcp and *http in destructor
 private:
 class TCPSocket;
 TCPSocket *tcp;
 class HTTP;
 HTTP *http;
};
class Manager::Transport::TCPSocket {};
class Manager::Transport::HTTP {};
class Manager::WinAPI 
{ 
 ... 
};

This is the first time I've built a large embedded application - are there any issues/other considerations I should consider before taking this approach?

• Jerry Coffin: As a (sort of) aside, a class named just "Manager" makes me immediately wonder whether this might not be some close relative of a God Class.
• Sjoerd: You'll want to define or delete the copy-constructor and/or assignment operator (and the move versions of those) to avoid certain bugs. Look up the Rule of Three / Rule of Five.

Answer 1

Immediate questions are:

1. Are TCP sockets and HTTP connections really specific to your Manager::Transport nested class?
2. How will you unit test them if they're not accessible outside Manager?
3. Will anything other than a Manager ever need a Transport?

to which at a guess I'd probably answer No, With unnecessary difficulty, and Maybe, respectively.

You don't need this nesting to modularize the code - if anything it seems to have encouraged moving unrelated declarations into the same place.

Socket wrapper, and logical connection objects, look like part of a platform abstraction layer. This would normally go below your business object layer, not inside it.

• Frank Hileman: "Below" and "Inside" are basically the same thing, from the perspective of abstraction. I think the question is more about encapsulation. If the author can do the necessary testing and preserve encapsulation, that is the best.
• Useless: Even if the fact that your Manager uses Sockets is an implementation detail worth encapsulating, Sockets are a well-understood abstraction independent of what you do with them. I'd normally use nested classes when factoring out implementation details that don't make any sense outside the original class, and could never be used in isolation.
• Babra Cunningham: @Useless thanks for this answer and comments - very helpful.
• Frank Hileman: @Useless bad username! Your comment is very useful!