I'm sure there is a better way to design this:
I have a class whose main purpose in life is to look after other classes which look after smaller things. These smaller classes have a limited amount of public data, a few methods which should only be accessible from the manager class, and a group of internal functions which should only be accessible from itself.
I was going to make the manager class a friend, but this will allow the manager to see (and use) the internal functions of the smaller class, which isn't ideal.
class child
{
public:
int x;
private:
friend class manager;
doSomething();
internalWork();
};
class manager
{
public:
child c;
};
manager m;
int i = m.c.x; // OK
c.doSomething(); // From method inside 'manager': OK
c.internalWork(); // Not allowed, only 'child' can use this function
Any ideas?
I program for a living; I work at a software company. I have a boss who will occasionally give me a task to do.
When he gives me a task, he simply says "Go write this widget, then commit it to source control. Then tell QA to test it."
What he doesn't do is tell me "Go write this widget, then commit it to source control. Then tell QA to test it," and then come over to my desk and start writing code. He's telling me what to do -- not doing it himself.
But that's basically what your manager class is doing when you do: c.internalWork(); -- the manager isn't telling the child object what to do; the manager is doing it.
friends are a code smell. They aren't necessarily a bad thing, and they certainly have their uses -- but they are the kind of thing that should make you sit back and think, "Do we really need this here?" In this case, the use of friend is a hack around a design flaw. The design flaw is the fact that your child classes don't have a public interface through which the manager can tell them what to do. The hack is the fact that your manager class is just throwing it's hands up and doing the work itself.
Fix your classes so that they have a proper interface, and get rid if the friendship.