Delegation

D

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;
}
 
P

Phlip

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.
 
D

DPfan

Phlip said:
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.


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.

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?
 
A

Agent Mulder

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;
}
 
P

Phlip

Delegation is good if users of F generally remain unaware of all Es in
the
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.
 
S

Sandeep

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/RealtimeMantra/HeaderFileIncludePatterns.htm

Sandeep
 
P

Phlip

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++/.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,145
Messages
2,570,826
Members
47,372
Latest member
LucretiaFo

Latest Threads

Top