By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,192 Members | 1,818 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,192 IT Pros & Developers. It's quick & easy.

Delegation

P: n/a
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;
}
Jul 19 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
> Is the following so-called "delegation"?

Yep.
If not how to make some changes so
that the F class delegates its operation to an E instance.
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.
On the other hand the following code runs without any problem. Is there any potential problems with it?


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
Jul 19 '05 #2

P: n/a
Phlip <ph*******@yahoo.com> wrote in message
news:pj*****************@newssvr32.news.prodigy.co m...
Is the following so-called "delegation"?
Yep.
If not how to make some changes so
that the F class delegates its operation to an E instance.


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.
On the other hand the following code runs without any problem. Is there

any
potential problems with it?


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


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?
Jul 19 '05 #3

P: n/a
<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;
}

</>
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<iostream>
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(){delete e;}
void Draw_F() { e->Draw_E( 123, 456 ); cout << "Draw in F" << endl; }

};

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


Jul 19 '05 #4

P: n/a
> > 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.

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?


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
Jul 19 '05 #5

P: n/a
> 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?


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/RealtimeMa...dePatterns.htm

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Generate Sequence Diagrams and Use Cases in PDF
Jul 19 '05 #6

P: n/a
> 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.
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.
See the following article for decoupling of header files:


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

--
Phlip
http://www.c2.com/cgi/wiki?TestFirstUserInterfaces
Jul 19 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.