Delegation

[DPfan]

Is the following so-called "delegation "? If not how to make some changes so
that the F class delegates its operation to an E instance.

On the other hand the following code runs without any problem. Is there any
potential problems with it?

class E
{
public:
void Draw_E(int a, int b) { cout << "Draw in E " << a*b<< endl; }
};

class F
{
E *e;
public:
void Draw_F() { e->Draw_E( 123, 456 ); cout << "Draw in F" << endl; }
};

int main(void){
F f;
f.Draw_F();
return 0;
}

[Phlip]

Re: Delegation

> Is the following so-called "delegation "?

Yep.
[color=blue]
> If not how to make some changes so
> that the F class delegates its operation to an E instance.[/color]

Delegation has no direct language support, so you "just do it".

Delegation means that users of F are unaware that a secret E performed
Draw_F.
[color=blue]
> On the other hand the following code runs without any problem. Is there[/color]
any[color=blue]
> potential problems with it?[/color]

Delegation is good if users of F generally remain unaware of all Es in the
program. This is an example of "decoupling ".

Delegation is bad if F has no other reason to exist, or if users of F could
have used E and simplified the program. Maybe F should be unaware of E.

--
Phlip

http://www.c2.com/cgi/wiki?TestFirstUserInterfaces

[DPfan]

Re: Delegation

Phlip <phlip_cpp@yaho o.com> wrote in message
news:pjhnb.1638 7$ce5.641@newss vr32.news.prodi gy.com...[color=blue][color=green]
> > Is the following so-called "delegation "?[/color]
>
> Yep.
>[color=green]
> > If not how to make some changes so
> > that the F class delegates its operation to an E instance.[/color]
>
> Delegation has no direct language support, so you "just do it".
>
> Delegation means that users of F are unaware that a secret E performed
> Draw_F.
>[color=green]
> > On the other hand the following code runs without any problem. Is there[/color]
> any[color=green]
> > potential problems with it?[/color]
>
> Delegation is good if users of F generally remain unaware of all Es in the
> program. This is an example of "decoupling ".
>
> Delegation is bad if F has no other reason to exist, or if users of F[/color]
could[color=blue]
> have used E and simplified the program. Maybe F should be unaware of E.
>
> --
> Phlip
> http://www.c2.com/cgi/wiki?TestFirstUserInterfaces
>
>[/color]

Thank you very much!

Notice that in class F, there's no instance of class E, but a pointer. Then
inside Draw_F() function Draw_E() is called with a statement "e->Draw_E."
Is this good way to do delegation? Is this good coding in C++ in general?

[Agent Mulder]

Re: Delegation

<DPfan>[color=blue]
> Is the following so-called "delegation "? If not how to make some changes so
> that the F class delegates its operation to an E instance.
>
> On the other hand the following code runs without any problem. Is there any
> potential problems with it?
>
> class E
> {
> public:
> void Draw_E(int a, int b) { cout << "Draw in E " << a*b<< endl; }
> };
>
> class F
> {
> E *e;
> public:
> void Draw_F() { e->Draw_E( 123, 456 ); cout << "Draw in F" << endl; }
> };
>
> int main(void){
> F f;
> f.Draw_F();
> return 0;
> }
>[/color]
</>


I wonder why it does run correct. Possibly luck. The
object pointed to by E*e is never created. I added
a constructor and a destructor.

-X

#include<iostre am>
class E
{
public:
void Draw_E(int a, int b) { cout << "Draw in E " << a*b<< endl; }
};

class F
{
E *e;

public:
F():e(new E){}
virtual~F(){del ete e;}
void Draw_F() { e->Draw_E( 123, 456 ); cout << "Draw in F" << endl; }

};

int main(void){
F f;
f.Draw_F();
return 0;
}

[Phlip]

Re: Delegation

> > Delegation is good if users of F generally remain unaware of all Es in
the[color=blue][color=green]
> > program. This is an example of "decoupling ".
> >
> > Delegation is bad if F has no other reason to exist, or if users of F[/color]
> could[color=green]
> > have used E and simplified the program. Maybe F should be unaware of E.[/color][/color]
[color=blue]
> Notice that in class F, there's no instance of class E, but a pointer.[/color]
Then[color=blue]
> inside Draw_F() function Draw_E() is called with a statement "e->Draw_E."
> Is this good way to do delegation? Is this good coding in C++ in general?[/color]

No. Always use the simplest and weakest thing.

Agent Mulder pointed out you had no E instance, so he added 'new'.

You could also fix that by removing the *, and replacing the -> with a dot .

In terms of OO design theory, delegation does not require *, or . ; only
that F know an E ready for the job. "Know" means "can access".

In terms of program stability, don't point without overwhelming need. Prefer
actual things, and pass them by reference. Don't point to character arrays -
use std::string. Don't point to arrays - use std::list or std::vector.

So your simplest delegation lets F have a member of type E.

--
Phlip

[Sandeep]

Re: Delegation

> Notice that in class F, there's no instance of class E, but a pointer. Then[color=blue]
> inside Draw_F() function Draw_E() is called with a statement "e->Draw_E."
> Is this good way to do delegation? Is this good coding in C++ in general?[/color]

The main advantage of delegation is that you can reduce the dependencies.
In this example, you can get by without including the header file
for E within F if the implemntation of the delegating function is placed
in the CPP file.

See the following article for decoupling of header files:

http://www.eventhelix.com/RealtimeMantra/HeaderFileIncludePatterns.htm

Sandeep
--

http://www.EventHelix.com/EventStudio

EventStudio 2.0 - Generate Sequence Diagrams and Use Cases in PDF

[Phlip]

Re: Delegation

> The main advantage of delegation is that you can reduce the dependencies.[color=blue]
> In this example, you can get by without including the header file
> for E within F if the implemntation of the delegating function is placed
> in the CPP file.[/color]

Per "always use the simplest and weakest thing", then if you have more than
one user of E, or if E's header requirements are more complex than F's, you
may benefit from putting E in a different header from F's, and
forward-declaring it in F's header.

However, if nobody else uses Es without Fs, you may lose the benefits of
putting it in a separate header.

Organically, as E grows the pressures increase to remove its dependencies
from F's. But as E shrinks pressures increase to put it inside F's header,
or inside F, or even inside F's implementation file.
[color=blue]
> See the following article for decoupling of header files:[/color]

/Large Scale C++ Software Design/ and /Exceptional C++/.

--
Phlip

http://www.c2.com/cgi/wiki?TestFirstUserInterfaces