design question - member function argument or pointer member

[Gert Van den Eynde]

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()(clas sB& 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

[Sharad Kala]

Re: design question - member function argument or pointer member


"Gert Van den Eynde" <gvdeynde@hotma il.com> wrote in message
news:bv2o67$81u $1@naxos.belnet .be...[color=blue]
> 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()(clas sB& 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,[/color]

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

[VANNA CHHUM]

Re: design question - member function argument or pointer member


"Gert Van den Eynde" <gvdeynde@hotma il.com> wrote in message
news:bv2o67$81u $1@naxos.belnet .be...[color=blue]
> 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[/color]
to[color=blue]
> pass a reference to the object of class B to the member function like this
> operator()(clas sB& 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[/color]
or[color=blue]
> 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[/color]

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

[Gert Van den Eynde]

Re: design question - member function argument or pointer member

>[color=blue]
> 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.
>[/color]

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.membe rfunctionofclas sC() and the like. What about
memory and data-duplication?

gert

[Sharad Kala]

Re: design question - member function argument or pointer member


"Gert Van den Eynde" <gvdeynde@hotma il.com> wrote in message
news:bv2r0p$ahi $1@naxos.belnet .be...[color=blue][color=green]
> >
> > 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.
> >[/color]
>
> 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.membe rfunctionofclas sC() and the like. What about
> memory and data-duplication?[/color]

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

[Gert Van den Eynde]

Re: design question - member function argument or pointer member

[color=blue]
> 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.[/color]

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

gert

[Sharad Kala]

Re: design question - member function argument or pointer member


"Gert Van den Eynde" <gvdeynde@hotma il.com> wrote in message
news:bv2tlr$d6n $1@naxos.belnet .be...[color=blue]
>[color=green]
> > 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.[/color]
>
> Some other classes D and E need the same object of class B do to their work.[/color]

If you think that a single instance of class B is used by all your other classes
then make it a singleton.

[Daniel T.]

Re: design question - member function argument or pointer member

Gert Van den Eynde <gvdeynde@hotma il.com> wrote:
[color=blue]
> 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()(clas sB& 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?[/color]

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.

[Keith H Duggar]

Re: design question - member function argument or pointer member

So far all of the postings have focused on inheritance, composition, etc.
However, in your original question you stated :
[color=blue]
> object of class A needs for example for the
> operator() and object of class B[/color]

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.