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

inheritance and composition

P: n/a

class Client {
public:
Client();
virtual void login()=0;
};
Client::Client(){}

class Play : public Client {
public:
Play();
void login();
};
Play::Play() Client(){}
void Play::login(){ /*...*/};

class Work : public Client {
public:
Work();
void login();
};
Work::Work() Client(){}
void Work::login(){ /*...*/};

class Conn_task {
protected:
Work wo;
Play pl;
void est_con();
public:
Conn_task();
};
Conn_task::Conn_task(){}
void Conn_task::est_con(){
if( some_bool_value) wo.login(); else pl.login();
}

class Spac_task : public Conn_task {
public:
void preform();
};
void Spac_task::preform(){
est_con();
}

my question is: how can I move the definition of login to the
real-estate of Client and be sure Client knows which class type
called it when est_con() is called?

thanks
Nov 16 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a

Gary Wessle wrote:
class Client {
public:
Client();
virtual void login()=0;
};
Client::Client(){}

class Play : public Client {
public:
Play();
void login();
};
Play::Play() Client(){}
void Play::login(){ /*...*/};

class Work : public Client {
public:
Work();
void login();
};
Work::Work() Client(){}
void Work::login(){ /*...*/};

class Conn_task {
protected:
Work wo;
Play pl;
void est_con();
public:
Conn_task();
};
Conn_task::Conn_task(){}
void Conn_task::est_con(){
if( some_bool_value) wo.login(); else pl.login();
}

class Spac_task : public Conn_task {
public:
void preform();
};
void Spac_task::preform(){
est_con();
}

my question is: how can I move the definition of login to the
real-estate of Client and be sure Client knows which class type
called it when est_con() is called?

thanks
Use Virtual inheritance for your Client class as a first because right
know you have 2 instances of client floating around. Basically when you
use virtual inheritance, the most derived class needs to call the
constructor of the virtual base class. You could use a protected member
variable in the Client class that could be set by the resp child
classes in their constructor and that could be used whenever login
function in the client is called.
There could be other solutions but this what popped up in my mind when
I saw the minimal code that was posted.

Nov 16 '06 #2

P: n/a

On Nov 16, 4:49 pm, Gary Wessle <phd...@yahoo.comwrote:
class Client {
public:
Client();
virtual void login()=0;};Client::Client(){}

class Play : public Client {
public:
Play();
void login();};Play::Play() Client(){}
void Play::login(){ /*...*/};

class Work : public Client {
public:
Work();
void login();};Work::Work() Client(){}
void Work::login(){ /*...*/};

class Conn_task {
protected:
Work wo;
Play pl;
void est_con();
public:
Conn_task();};Conn_task::Conn_task(){}
void Conn_task::est_con(){
if( some_bool_value) wo.login(); else pl.login();

}class Spac_task : public Conn_task {
public:
void preform();};void Spac_task::preform(){
est_con();

}my question is: how can I move the definition of login to the
real-estate of Client and be sure Client knows which class type
called it when est_con() is called?

thanks
you can use the Visitor pattern

HTH
Radu

Nov 17 '06 #3

P: n/a
am******@gmail.com wrote:
Use Virtual inheritance for your Client class as a first because right
know you have 2 instances of client floating around. Basically when you
use virtual inheritance, the most derived class needs to call the
constructor of the virtual base class. You could use a protected member
variable in the Client class that could be set by the resp child
classes in their constructor and that could be used whenever login
function in the client is called.
There could be other solutions but this what popped up in my mind when
I saw the minimal code that was posted.
HUH ???????????????????????????????????????????

Nov 17 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.