Class composed of other, larger, classes problem

Question

Imagine you have a class with dozens of private member variables. Each member variable has a public getter and a setter function:

class Foo
{
public:
   int GetA() const { return m_a; }
        :
   int GetZ() const { return m_z; }

   void SetA(int val) { m_a = val; }
        :
   void SetZ(int val) { m_z = val; }

private:
   int m_a;
        :
   int m_z
};

Now we have a second class, which is composed of Foo (amongst other things):

class Bar
{
private:
   // some instances of other classes of about the same complexity as Foo
   Foo m_foo;
};

So Bar is essentially a class which binds together instances of other classes in a single entity.

Functions which are passed an instance of Bar will want to access m_foo so that they can call its getter and setter functions. Mindful of Scott Meyers advice in Effective C++ (3rd edition - item #28), I'm reluctant to add something which return a 'handle' to m_foo, e.g.

Foo& GetFoo() const { return m_foo; }   // dubious const, I know

Do I have any other options though other than replicating every single getter and setter in Bar?

I'm working with some legacy code which is lazy enough to make 'm_foo' public! But this goes against some other of Scott's advice (item #22 in this case - "declare data members private").

Any way out of this bind?

Answer 1

You should make the data member public.

It already is conceptually public, anyway, if you give Bar getters and setters like you describe. This applies similarly to any getter/setter pair where the getter returns a reference. (Except you can include pre/post hooks, but that's a separate issue than encapsulation.)

Answer 2

If you now anyway have such large classes with getters and setters I don't think its a problem to return the reference to that object, after all there is still a layer in between - you essentially still have control over what is set/get in Foo.

OTOH maybe if you are designing your class to have lots of public properties maybe you should reconsider your design, the more stuff in the class the more unwieldy it is.

EDIT: maybe you could change the data structure of your public members and place them in a map of some sort? that way it would at least save some writing. :-)

get("propertyname")
set("propertyname",value)

Answer 3

Imagine you have a class with dozens of private member variables. Each member variable has a public getter and a setter function.

Um, I'd rather not. Read here why this is a bad idea.

Answer 4

Not really, no. You can create forwarding getter and setter for every single getter or setter in foo. You can make the foo instances public or you can create a getter and setter for foo.

Generally I've found, that when facing this sort of situation, it is better to revisit my reasons for encapsulating the data in foo and bar as I have done. Often I will find that it is possible to break foo up into multiple classes and then move the functions that need to access each part of foo's data into the appropriate class as methods. This leads to variables that are actually private member variables of their classes and eliminates the need for setters and getters. This is how object oriented programming is supposed to work.

For a good guide on doing this to legacy code, take a look at Martin Fowler's Refactoring.