design question - member function argument or pointer member

Discussion in 'C++' started by Gert Van den Eynde, Jan 26, 2004.

  1. Hi all,

    I have a question on interface design: I have a set of objects that are
    interlinked in the real world: object of class A needs for example for the
    operator() an object of class B. On what arguments do you decide whether to
    pass a reference to the object of class B to the member function like this
    operator()(classB& objB) or to have in class A a data member (a const
    pointer to a class B object or so) and have this set during construction or
    with a Set-function? Class B is designed to deliver the necessary data
    through Get-functions. Or do friends come in handy here?

    Thanks for tips,

    gert
     
    Gert Van den Eynde, Jan 26, 2004
    #1
    1. Advertising

  2. Gert  Van den Eynde

    Sharad Kala Guest

    "Gert Van den Eynde" <> wrote in message
    news:bv2o67$81u$...
    > Hi all,
    >
    > I have a question on interface design: I have a set of objects that are
    > interlinked in the real world: object of class A needs for example for the
    > operator() an object of class B. On what arguments do you decide whether to
    > pass a reference to the object of class B to the member function like this
    > operator()(classB& objB) or to have in class A a data member (a const
    > pointer to a class B object or so) and have this set during construction or
    > with a Set-function? Class B is designed to deliver the necessary data
    > through Get-functions. Or do friends come in handy here?
    >
    > Thanks for tips,


    I think you need containment of B object inside A class.
    It's a HAS-A kind of relationship.
    If a class is implemented in terms of another class then containment/private
    inheritance needs to be used
    You say classes A and B are related. Then B object should also get constructed
    when your A object gets constructed.
    I personally do not like Set/Get functions. They kind of reflect that a class
    has been used just for name-sake.

    Best wishes,
    Sharad
     
    Sharad Kala, Jan 26, 2004
    #2
    1. Advertising

  3. Gert  Van den Eynde

    VANNA CHHUM Guest

    "Gert Van den Eynde" <> wrote in message
    news:bv2o67$81u$...
    > Hi all,
    >
    > I have a question on interface design: I have a set of objects that are
    > interlinked in the real world: object of class A needs for example for the
    > operator() an object of class B. On what arguments do you decide whether

    to
    > pass a reference to the object of class B to the member function like this
    > operator()(classB& objB) or to have in class A a data member (a const
    > pointer to a class B object or so) and have this set during construction

    or
    > with a Set-function? Class B is designed to deliver the necessary data
    > through Get-functions. Or do friends come in handy here?
    >
    > Thanks for tips,
    >
    > gert


    Hi,
    These are good questions with no "right" answers, though many will try to
    tell you what is "right". The question here is, "who is managing the
    B-object"? If you want to hide what is happening to B, then it might be a
    good idea to encapsulate the object inside of A (by composition, I mean).
    If you have another set of code which is managing both an A and a B, then it
    probably does not make much sense (to place a B object inside of A).

    Overriding, that last suggestion, however, is that if the B-object is
    needed in the implementation of A, then you probably do want it in your
    A-class design (or use inheritance, possibly - not likely here).

    Again, it's kind of silly...what I wrote. I can think of so many
    scenarios where this rule of thumb would be... silly.
    If you are fairly new to C++ or this type of design decision making
    process, then I recommend that you try as many ways as you can think of.
    Look at the tradeoffs of using each technique. Rules of thumb break easily
    in C++ world, though many do exist. Try to get some experience with these
    decisions and get a feel for what you like most.

    Some (sometimes) competing ideas:
    Friends
    Inheritance (private, protected, public)
    Composition (a B inside of an A) by value
    Composition by reference
    etc.

    People will tell you inherit in a "IS-A" relationship and compose in a
    "HAS-A" relationship. I don't stick hard and fast to this notion. Many
    times, I strive hard to keep away from inheritance and virtual functions.
    Not always - sometimes it is the best solution for me - it's just that
    things better be really ripe for inheritance before I'll use it.

    Anyway, look up H. Sutter's words of wisdom on inheritance and composition
    (Exceptional C++ and More Exceptioinal C++). Lippman's book has some good
    stuff too (C++ Primer). And, of course, B. Stroustrop will undoubtedly have
    some great guidelines for you (The C++ Programming Language).

    Shane
     
    VANNA CHHUM, Jan 26, 2004
    #3
  4. >
    > I think you need containment of B object inside A class.
    > It's a HAS-A kind of relationship.
    > If a class is implemented in terms of another class then
    > containment/private inheritance needs to be used
    > You say classes A and B are related. Then B object should also get
    > constructed when your A object gets constructed.
    > I personally do not like Set/Get functions. They kind of reflect that a
    > class has been used just for name-sake.
    >


    ok, but suppose a third class C pops that has a HAS-A relationship with B.
    If I compose again, then I end up in the implementation of class A with
    this like objB.objC.memberfunctionofclassC() and the like. What about
    memory and data-duplication?

    gert
     
    Gert Van den Eynde, Jan 26, 2004
    #4
  5. Gert  Van den Eynde

    Sharad Kala Guest

    "Gert Van den Eynde" <> wrote in message
    news:bv2r0p$ahi$...
    > >
    > > I think you need containment of B object inside A class.
    > > It's a HAS-A kind of relationship.
    > > If a class is implemented in terms of another class then
    > > containment/private inheritance needs to be used
    > > You say classes A and B are related. Then B object should also get
    > > constructed when your A object gets constructed.
    > > I personally do not like Set/Get functions. They kind of reflect that a
    > > class has been used just for name-sake.
    > >

    >
    > ok, but suppose a third class C pops that has a HAS-A relationship with B.
    > If I compose again, then I end up in the implementation of class A with
    > this like objB.objC.memberfunctionofclassC() and the like. What about
    > memory and data-duplication?


    Hold pointers/references to the contained class. This way you need to be careful
    to
    correctly initialize them when the enclosing object gets created. This way your
    objects do not become
    memory intensive. Also at time of destruction you need to be careful to free up
    the used memory.

    Each A object holds a unique reference to some B object and so on.
    A object initializes B when it gets created.
    I don't understand how data-duplication comes into picture.
    If your contained object has no state and you mean that all contained objects
    are similar then then it should not be declared as a class in the first place.

    Best wishes,
    Sharad
     
    Sharad Kala, Jan 26, 2004
    #5

  6. > I don't understand how data-duplication comes into picture.
    > If your contained object has no state and you mean that all contained
    > objects are similar then then it should not be declared as a class in the
    > first place.


    Some other classes D and E need the same object of class B do to their work.

    gert
     
    Gert Van den Eynde, Jan 26, 2004
    #6
  7. Gert  Van den Eynde

    Sharad Kala Guest

    "Gert Van den Eynde" <> wrote in message
    news:bv2tlr$d6n$...
    >
    > > I don't understand how data-duplication comes into picture.
    > > If your contained object has no state and you mean that all contained
    > > objects are similar then then it should not be declared as a class in the
    > > first place.

    >
    > Some other classes D and E need the same object of class B do to their work.


    If you think that a single instance of class B is used by all your other classes
    then make it a singleton.
     
    Sharad Kala, Jan 26, 2004
    #7
  8. Gert  Van den Eynde

    Daniel T. Guest

    Gert Van den Eynde <> wrote:

    > I have a question on interface design: I have a set of objects that are
    > interlinked in the real world: object of class A needs for example for the
    > operator() an object of class B. On what arguments do you decide whether to
    > pass a reference to the object of class B to the member function like this
    > operator()(classB& objB) or to have in class A a data member (a const
    > pointer to a class B object or so) and have this set during construction or
    > with a Set-function? Class B is designed to deliver the necessary data
    > through Get-functions. Or do friends come in handy here?


    Which is easer for the client (code that uses A)? That is what you
    should do. If you find that clients are constantly calling "setB" before
    calling A's member-function that uses B, then you would be better off
    passing a B in as a parameter of the member-function. If clients are
    constantly having to track which B goes with which A, then having A hold
    a B member variable is the right way to go.
     
    Daniel T., Jan 26, 2004
    #8
  9. So far all of the postings have focused on inheritance, composition, etc.
    However, in your original question you stated :

    > object of class A needs for example for the
    > operator() and object of class B


    Allow me to paraphrase your statement :

    A::somefunction() requires and object of class B

    In that case why not follow your own suggestion of :

    A::somefunction ( B const & b ) { ... }

    This is what the argument list of a function are for, to supply the arguments a
    function needs to carry out its work. This seems to solve all of the problems
    you have outline. Namely :

    1) A::somefunction is guaranteed to have an available B or it could not have
    been called.

    2) If other class functions require the same instance of B then simply pass
    that instance to them as well :

    C::somefunction ( B const & b ) { ... }
    D::somefunction ( B const & b ) { ... }
    etc ...

    This method also has many other advantages :

    1) class are not required to hold pointers or references to objects they may or
    may not use. (After all, what guarantee do we have that the client will even
    call somefunction.) This falls under the "only pay for what you use" paradigm
    with C++ supports very well.

    2) you can run A::somefunction multiple times with different B objects with a
    single function call.

    3) you can run A::somefunction, B::somefunction, ... , X::somefunction with
    different B objects at your discretion.

    In essence, this exactly what functions are designed to do: take arguments and
    do work using them.
     
    Keith H Duggar, Jan 26, 2004
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. glen stark
    Replies:
    2
    Views:
    716
    Ron Natalie
    Oct 10, 2003
  2. Fraser Ross
    Replies:
    4
    Views:
    1,066
    Fraser Ross
    Aug 14, 2004
  3. Vijai Kalyan
    Replies:
    4
    Views:
    723
    Vijai Kalyan
    Nov 8, 2005
  4. Reckoner
    Replies:
    11
    Views:
    717
    Steven D'Aprano
    Jan 19, 2009
  5. somenath
    Replies:
    2
    Views:
    170
    somenath
    Aug 29, 2013
Loading...

Share This Page