Sharing data with an encapsulated class

Discussion in 'C' started by ever_thus, Jan 8, 2007.

  1. ever_thus

    ever_thus New Member

    Joined:
    Jan 3, 2007
    Messages:
    53
    Likes Received:
    0
    Trophy Points:
    0
    I have a class called MenuItem which holds the information for a menu item in an owner-draw menu. Some methods are to be called on all the items, so I created a class called MenuVector which calls the "global" methods on each MenuItem. Since MenuVector is a container is inherits from the STL vector.

    MenuItem has some static variables. I realised that these static variables are essentially "global" to all MenuItems, and therefore should belong as memebers of MenuVector. Furthermore it might in the future be desireable to have MenuVector perform operations on these variables. However making them members of MenuVector means that MenuItem no longer has access to them, which it needs.

    I do not want to amke these members accessible outside of MenuItem and MenuVector so as to preserve information hiding. I originally thought of making MenuItem a friend of MenuVector. However I don't want to do this as I might not be able to port the application to other languages in the future. What is the proper OO way to share data with an encapsulated class?
     
  2. shabbir

    shabbir Administrator Staff Member

    Joined:
    Jul 12, 2004
    Messages:
    15,375
    Likes Received:
    388
    Trophy Points:
    83
    My vote goes to have MenuItem should contain the class MenuVector. A class within the class and you have the object of the inner class and can access it from the outside only through the MenuItem. As far as I see MenuVector holds the data of MenuItem.

    I sm sure others will have some more opinions on this as well.
     
  3. ever_thus

    ever_thus New Member

    Joined:
    Jan 3, 2007
    Messages:
    53
    Likes Received:
    0
    Trophy Points:
    0
    Perhaps I wasn't clear. MenuItem contains instance members that are specific to each menu item. MenuVector contains members global to the menu, including the individual menu items (MenuItems). That's why it inherits from vector.

    That being the case I don't see how MenuItem could contain MenuVector. Are you suggesting I have a third superclass. I still don't see how the encapsulated would get the access they need.
     
  4. DaWei

    DaWei New Member

    Joined:
    Dec 6, 2006
    Messages:
    835
    Likes Received:
    5
    Trophy Points:
    0
    Occupation:
    Semi-retired EE
    Location:
    Texan now in Central NY
    Home Page:
    http://www.daweidesigns.com
    Perhaps I'm misconstruing your requirements. Why not just a base class (MenuVector) that contains all the common data and methods. The various MenuItems then inherit those and add or override where individualization is needed.

    It is probably a mistake to constrain your detail design to means that are portable to other languages. For high-level functionality, fine, but not for detail. I don't think you would be able to port detail in, say, C++, Python, and Haskell, without making any of the three much poorer than it had to be.
     
  5. ever_thus

    ever_thus New Member

    Joined:
    Jan 3, 2007
    Messages:
    53
    Likes Received:
    0
    Trophy Points:
    0
    I trying to have an instance of an container object conatining all the common data and methods as well as on the individual MenuItems. An instance (rather than a class) is needed because these methods will need to be called to iterate on the individual MenuItems and possibly on the shared data. Inheriting from a base class simply gives each MenuItem its own copy of the shared data and methods. This makes each class responsible for global operations, which should be the responsibility of the container.

    If I'm forced to use friends I guess I have no choice, but I'd like to avoid it. I won't be porting line for line obviously, but I'd like the basic OO design to remain the same.
     
  6. DaWei

    DaWei New Member

    Joined:
    Dec 6, 2006
    Messages:
    835
    Likes Received:
    5
    Trophy Points:
    0
    Occupation:
    Semi-retired EE
    Location:
    Texan now in Central NY
    Home Page:
    http://www.daweidesigns.com
    Maybe I'm dense, today. If you instantiate a menu item that inherits form a menu class with common methods, and you don't override those, then calling the common method will invoke the method from the parent class.
     
  7. ever_thus

    ever_thus New Member

    Joined:
    Jan 3, 2007
    Messages:
    53
    Likes Received:
    0
    Trophy Points:
    0
    Yes, it will perform the inherited task, but only once on itself. It cannot be coded to perform the task on all instantiated children, for obvious reasons. I want the same task performed for each MenuItem.

    What is more, when performing operations on the inherited variables it it would change them one MenuItem at a time. I want one MenuVector method call to be able to change the shared variables, so it makes sense for them to be members of MenuVector rather than have copies in each MenuItem.

    To illustrate: If I were to be writing these tasks without a class I would need to iterate over each MenuItem and pass the same parameters on each iteration. So the class I want will also do that. However to keep encapsulation (as in OOD encapsulation; not as in the title of this thread) as well as to ensure all MenuItems are synchronized, I want a class that can hold one copy of these parameters for the MenuItems memebers and iterate a function over all the MenuItems with one call to the corrsponding MenuVector function or change the single copy of the shared variables with one MenuVector method call.

    Think of it as a vector and iterator with built in actions (which is why it inheits from STL's vector). It is not a menu item template.

    I hope I've made myself clear.
     
  8. shabbir

    shabbir Administrator Staff Member

    Joined:
    Jul 12, 2004
    Messages:
    15,375
    Likes Received:
    388
    Trophy Points:
    83
    This is not a good design and probably I could not get this from the first post but I think a class having all the data i.e. about menu as well as MenuItem is not a good one. break them up in 2 parts and have each of them as a contained class or even an abstract or a simple base class.
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice