Acceptable design to use public member objects in composition?

Question

Say I have a large class called Root, which has a lot of members & functions:

class Root {
public:
    void func1(); // operates on a and b
    void func2(); 
    ...       
private:
    A a;
    B b;
    C c;
    ...
};

The class Root is getting a bit big so I decide to factor out a few of the member variables and a function into another class:

class AB {
public:
    void func1();
    ...
private:
    A a;
    B b;
};

Then using composition I can make AB ab a member variable of Root. Root is now a bit smaller / cleaner / more manageable. The question is about the access level of ab after this composition refactor.

Is it OK in this case for ab to be a public member? Any downsides? Public members are generally considered bad design from what I've read. But here the overall encapsulation / exposure hasn't actually changed...the objects a and b are private within AB so are still hidden from the outside.

(Sidenote: the reason why I would like to make ab public is that it allows easier traversing of Root's composition hierarchy. For example in Root's member c I might want to call func1:

void C::foo(Root& root) {
    //do some stuff
    root.ab.func1();
}

If ab was private then I'd have to define a pass-through function in root.)

Answer 1

If class C wants to call func1() then pass the ab object to C's foo function instead of passing the root object. This better describes what is going on to other programmers and future you. It tells you that C does't need all of Root to do its job, it only needs AB (and it could conceivably get an AB from some source other than Root.)

void C::foo(AB& ab) {
    //do some stuff
    ab.func1();
}

If I were you, I would also go through and change any other class that is accessing Root merely to call AB's func1() (and whatever other functions you move into the AB class.

Do this with an eye toward breaking up Root in other ways as well. If it is very large like you say, then there are likely lots of little classes trying to get out...

Answer 2

From both an academic and a technical point of view, it is not okay.

From an academic point of view, you are violating the principle of encapsulation.

From a technical point of view, if you need to do any further refactoring in the future, you will have a lot of work to do.

That having been said, there is also a practical point of view, which boils down to this: if your IDE gives you the ability to refactor ab from public to private, adding all necessary accessors and replacing all references to root.ab with invocations of these accessors all over your entire code base, and if it can do that with just a couple of clicks and keystrokes, you are fine. If not, you are better off not doing it.

It is not clear to me what you mean by sub-object c, but if you mean a subclass, then consider making ab protected. This way, c will be able to access it, but no outside code will.