Thread: Encapsulation and objects within objects

Not quite sure what you mean. Class b can contain an object of class a, but that doesn't mean that it gets (or should get) access to the internals of that object. For instance, if I create a class that contains a std::string object, I use that just as I would a "normal" string object, using the public interface. All the member functions can access this variable regardless of its protection level. (ETA: And of course, the usual private/public rules apply; you can make the variable private and then provide get/set/whatever methods to restrict users' ability to mess with your data.)

Encapsulation means (among other things) that a container exhibits external characteristics that are derived from the contained objects, not that the container has to make the contained objects accessible to the external world.

As an example, the liver is an essential component of a human body (the body will die without it) but the liver is not generally accessed or controlled from outside the human body. As such, a class that implements a model of the human body might well contain a liver. However, it would not allow unfettered access for other objects to see, let alone directly control, that liver. Some externally visible actions of the human body (such as drinking) may have an indirect effect on how the liver operates (for example, alcohol may be ingested, absorbed into the blood stream from the stomach, and eventually metabolised by the liver). That does not require that a wine bottle somehow communicate directly with a liver.

Originally Posted by nair

If I define object B as an attribute of object A, must I always define it as a public member in order to use it? If it is defined as a private member, I cannot go to that attribute directly and use all of the methods built into object B. I will be attempting to violate the rules of private accessibility associated with object A.

You have to consider the context. If you are writing a member function of B, then regardless of whether the A member object is public or private, you can access the public members of the A member object. If you are writing code that uses a B object, then you (generally) cannot access any members of the A member object of B if the A member object is private.

So, I would answer your question as: no.

Originally Posted by nair

Maybe I am suppose to build methods into object A which are intended to call the object B methods? If that is possible, that seems like it might be a more desirable solution.

Yes.