Should component know its host?

[Krice]

There is a component class inside the host class:

class Host
{
Component *c;
....

In some cases Component needs to call the host and
I guess the only way is that you pass the host for it:

Component::Comp onent(Host *h)
{
h->Do_Something() ;
....

Somehow I think this is bad design, but how to avoid it?

[Victor Bazarov]

Krice wrote:

There is a component class inside the host class:

class Host
{
Component *c;
...

In some cases Component needs to call the host and
I guess the only way is that you pass the host for it:

Component::Comp onent(Host *h)
{
h->Do_Something() ;
...

Somehow I think this is bad design, but how to avoid it?

You could extract the behaviour the component needs into a separate
class and derive your host from that class. That way there is no direct
dependency.

Whether the existence of the dependency is acceptable depends on your
model, I guess (pun intended). Parents and children depend on each
other for different functionality, so, bidirectional interaction is not
unheard of in the real world...

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[mlimber]

On Aug 14, 4:20*pm, Krice <pau...@mbnet.f iwrote:

There is a component class inside the host class:

class Host
{
* Component *c;
...

In some cases Component needs to call the host and
I guess the only way is that you pass the host for it:

Component::Comp onent(Host *h)
{
* h->Do_Something() ;
...

Somehow I think this is bad design, but how to avoid it?

You could use a generic callback mechanism. Check out
std::tr1::funct ion if you have TR1 available or Boost.Function if you
don't. It would make your code look something like:

Component::Comp onent( const std::tr1::funct ion& prologFn )
{
prologFn();
// ...
}

Also similar is _Modern C++ Design_'s Loki::Function (http://loki-
lib.sourceforge .net).

Cheers! --M

[Daniel T.]

Krice <pa****@mbnet.f iwrote:

There is a component class inside the host class:

class Host
{
Component *c;
...

In some cases Component needs to call the host and
I guess the only way is that you pass the host for it:

Component::Comp onent(Host *h)
{
h->Do_Something() ;
...

Somehow I think this is bad design, but how to avoid it?

The typical OO solution is to make an abstract base class:

class HostBase {
public:
virtual void Do_Something() = 0;
};

class Base : public HostBase {
public:
void Do_Something();
};

class Component {
public:
Component( HostBase* hb ) {
hb->Do_Something() ;
}
};

I'm not so sure, though, if this is the best solution in this case... If
the component really is "inside" the host, then maybe the host should
call Do_Something() itself before constructing the component. If the
component is being created outside the host and passed into it, then
maybe the creator of the component should be calling Do_Something() on
the host.

[Paavo Helde]

Krice <pa****@mbnet.f ikirjutas:

There is a component class inside the host class:

class Host
{
Component *c;
...

In some cases Component needs to call the host and
I guess the only way is that you pass the host for it:

Component::Comp onent(Host *h)
{
h->Do_Something() ;
...

Somehow I think this is bad design, but how to avoid it?

In the component constructor it is quite easy to avoid, as suggested by
Daniel - just use a factory function for creating the components, which
additionally calls Host::Do_Someth ing() before or after the construction
as appropriate.

The situation gets more complicated if the component needs to call host
also later, from other member functions. By some reason (probably bad
design) I have had many such cases. Just passing the host pointer as you
show above, this is actually not so bad. What would be worse is to store
the host pointer or reference inside the component object. This could
potentially create a whole bunch of maintenance and lifetime issues. As a
simple solution, one could just pass the host pointer each time the
component needs it.

A side note: I would probably use a reference instead of a pointer here,
as most probably the Host object should remain alive throughout the call.

And yes, as other posters mentioned, it might be a good idea to restrict
the amount of interdependenci es by passing a pointer or reference to a
narrower interface instead of the full host (interface = ABC, host
derived from the interface).

hth
Paavo

[Krice]

On 14 elo, 23:29, Victor Bazarov <v.Abaza...@com Acast.netwrote:

You could extract the behaviour the component needs into a separate
class and derive your host from that class.

I want to avoid deriving.. anyway, the solution was simple
after all. I wanted to control the host from the component,
but I guess it should be the other way around so now the host
is controlling the (now simplified) component.