Encapsulation and objects within objects

This is a discussion on Encapsulation and objects within objects within the C++ Programming forums, part of the General Programming Boards category; While sticking with the theme of having private data members and public methods within all of the objects that I ...

  1. #1
    Registered User
    Join Date
    Oct 2010
    Posts
    30

    Encapsulation and objects within objects

    While sticking with the theme of having private data members and public methods within all of the objects that I create programming, I am a bit confused about the topic of encapsulation in the context of containing objects within objects.

    I have no experience with this, but I have reached a point in my own projects where I want to define objects as the data members of other objects. I sort of think of this has having a "parent object" which can contain one or multiple "child objects". Anyway, if a "child object" is defined as a private data member of a "parent object", how am I suppose to access or change the "child object" without making it publicly accessible? Are objects intended to be private data members of other objects in any context?

    I tried making my "child object" protected, not really knowing anything about the concept of protected members/methods (I've only used public and private up until now), but did not have any luck with that. Also, I read on cplusplus.com that there is a "friend" keyword which I believe can be used for the purposes I am describing--although I really don't know--but it was then described as something which was "out of an object-oriented programming methodology" Friendship and inheritance - C++ Documentation. I will read up more on both of these topics, but just figured you guys might know a quick fix for this problem, or would know immediately if I was going down the wrong path entirely. I am quite the beginner, so perhaps I am attempting to do something I shouldn't (ex. not following a best practice).

  2. #2
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    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.)
    Last edited by tabstop; 07-31-2011 at 12:03 AM.

  3. #3
    Registered User
    Join Date
    Jun 2005
    Posts
    6,646
    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.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  4. #4
    Registered User
    Join Date
    Oct 2010
    Posts
    30
    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.

    The only option I have made work is to define object B as a public member within object A. Now I can access the methods built into object B without the compiler complaining. 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.

  5. #5
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,274
    Quote 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.

    Quote 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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 1
    Last Post: 05-24-2011, 07:36 PM
  2. Objects as attributes of other objects.
    By kbro3 in forum C++ Programming
    Replies: 10
    Last Post: 08-15-2009, 04:46 PM
  3. Assigning objects to objects
    By Swordsalot in forum C++ Programming
    Replies: 4
    Last Post: 07-26-2006, 04:47 AM
  4. Replies: 4
    Last Post: 10-16-2003, 12:26 PM
  5. Objects, or pointers to objects?
    By Unregistered in forum C++ Programming
    Replies: 5
    Last Post: 12-18-2001, 12:57 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21