Is this an OO concept?

[Jason Heyes]

I use a template class called Derived to instantiate derived classes of
class Abstract. Is this an OO concept? Here is some code to illustrate:

#include <iostream>

class Abstract
{
public:
virtual void func() const = 0;

virtual ~Abstract() { }
};

template <typename T>
class Derived : public Abstract
{
T obj;
public:
Derived() { }

void func() const { obj.func(); }
};

class A
{
public:
void func() const
{ std::cout << "A::func called" << std::endl; }
};

class B
{
public:
void func() const
{ std::cout << "B::func called" << std::endl; }
};

int main()
{
Abstract *obj = new Derived<A>;
obj->func();

obj = new Derived<B>;
obj->func();
}

The output of the program is:

A::func called
B::func called

Thanks.

[Maxim Yegorushkin]

On Sun, 19 Jun 2005 09:39:07 +0400, Jason Heyes
<ja********@opt usnet.com.au> wrote:

I use a template class called Derived to instantiate derived classes of
class Abstract. Is this an OO concept?
Why do you care?
Here is some code to illustrate:

#include <iostream>

class Abstract
{
public:
virtual void func() const = 0;

virtual ~Abstract() { }
};

template <typename T>
class Derived : public Abstract
{
T obj;
public:
Derived() { }

void func() const { obj.func(); }
};

Derived template is the adapter design pattern. It uses object composition
to add Abstract interface to the contained object. And it's perfectly OO.

--
Maxim Yegorushkin

[Jason Heyes]

"Maxim Yegorushkin" <e-*****@yandex.ru > wrote in message
news:op.sslslho gti5cme@home...

On Sun, 19 Jun 2005 09:39:07 +0400, Jason Heyes
<ja********@opt usnet.com.au> wrote:

I use a template class called Derived to instantiate derived classes of
class Abstract. Is this an OO concept?
Why do you care?

I would like to find the right naming for my classes.

Here is some code to illustrate:

#include <iostream>

class Abstract
{
public:
virtual void func() const = 0;

virtual ~Abstract() { }
};

template <typename T>
class Derived : public Abstract
{
T obj;
public:
Derived() { }

void func() const { obj.func(); }
};

Derived template is the adapter design pattern. It uses object composition
to add Abstract interface to the contained object. And it's perfectly OO.

Ok. I'd better rename Derived to Adapter. Thanks for the information.

[forayer]

Jason Heyes wrote:

I use a template class called Derived to instantiate derived classes of
class Abstract. Is this an OO concept?

i hope u do realize the fact that only Derived (or now Adapter) is the
_only_ derived class of Abstract. classes A & B r diff classes. ur
template class imposes the restriction on objects that they must have
func() defined. i wouldnt exactly attribute such template restrictions
to OO. instead u might wanna try:

class Abstract {
public:
virtual void func() const = 0;
};

class Caller {
Abstract *x;
public:
Caller() { x = NULL; }
Caller(Abstract *x) { this->x = x; }
~Caller() { if(x) delete x; }
void func() { if(x) x->func(); }
void set_x(Abstract *x)
{ if(this->x) delete this->x;
this->x = x; }
// u might wanna try overloadin da = operator
// but keep in mind that <Caller obj> = new <Abstract derived> won't
work!
};

class A : public Abstract {
public:
void func() const { cout << "A" << endl; }
};

class B : public Abstract {
public:
void func() const { cout << "B" << endl; }
};

int main()
{
Caller c(new A);
c.func();
c.set_x(new B);
c.func();
return 0;
}

[david]

He is probably not allowed to modify A and B. If he could, then I don't
see why you would need a Caller class at all.

class Caller {
Abstract *x;
public:
Caller() { x = NULL; }
Caller(Abstract *x) { this->x = x; }
~Caller() { if(x) delete x; }
void func() { if(x) x->func(); }
void set_x(Abstract *x)
{ if(this->x) delete this->x;
this->x = x; }
// u might wanna try overloadin da = operator
// but keep in mind that <Caller obj> = new <Abstract derived> won't
work!
};
Well, i hope you realize you are passing a pointer to an object you have
not created and then you are deleting it in the destructor. That's not
good "OO" either. You need to keep in mind implementation details, too
bad. There are some typical solutions for such problems, like reference
counter, master pointers, or the simple thing of making responsible for
the deletion of the object to its creator.
forayer wrote: Jason Heyes wrote:

I use a template class called Derived to instantiate derived classes of
class Abstract. Is this an OO concept?

i hope u do realize the fact that only Derived (or now Adapter) is the
_only_ derived class of Abstract. classes A & B r diff classes. ur
template class imposes the restriction on objects that they must have
func() defined. i wouldnt exactly attribute such template restrictions
to OO. instead u might wanna try:

class Abstract {
public:
virtual void func() const = 0;
};

class Caller {
Abstract *x;
public:
Caller() { x = NULL; }
Caller(Abstract *x) { this->x = x; }
~Caller() { if(x) delete x; }
void func() { if(x) x->func(); }
void set_x(Abstract *x)
{ if(this->x) delete this->x;
this->x = x; }
// u might wanna try overloadin da = operator
// but keep in mind that <Caller obj> = new <Abstract derived> won't
work!
};

class A : public Abstract {
public:
void func() const { cout << "A" << endl; }
};

class B : public Abstract {
public:
void func() const { cout << "B" << endl; }
};

int main()
{
Caller c(new A);
c.func();
c.set_x(new B);
c.func();
return 0;
}

[Peter Julian]

"forayer" <th********@hot mail.com> wrote in message
news:11******** **************@ g49g2000cwa.goo glegroups.com.. .

Jason Heyes wrote:

> I use a template class called Derived to instantiate derived classes of> class Abstract. Is this an OO concept?

i hope u do realize the fact that only Derived (or now Adapter) is the
_only_ derived class of Abstract. classes A & B r diff classes. ur
template class imposes the restriction on objects that they must have
func() defined. i wouldnt exactly attribute such template restrictions
to OO. instead u might wanna try:

Bad design. And thanks for the memory leak. The Abstract class requires a
virtual destructor since you are deleting derived objects through an
Abstract pointer. Look up initialization lists as well.

#include <iostream>
#include <stdexcept>

class Abstract {
virtual ~Abstract() { std::cout << "~Abstract" \n; }
public:
virtual void func() const = 0;
};

class Caller {
Abstract *x;
public:
Caller() { x = NULL; }
Caller() : x(0) { }
Caller(Abstract *x) { this->x = x; }
Caller(Abstract *p) : x(p) { }
~Caller() { if(x) delete x; }
void func() { if(x) x->func(); }
void func() throw(std::exce ption)
{
try
{
if (x == 0)
throw std::exception( "Error: func() called on a null object\n");
x->func();
}
catch( const std::exception& e)
{
std::cout << e.what();
}
}
void set_x(Abstract *x)
{ if(this->x) delete this->x;
this->x = x; }
where is the copy constructor? If you choose to disable it:

private:
Abstract(const Abstract& r_copy_);
// u might wanna try overloadin da = operator
// but keep in mind that <Caller obj> = new <Abstract derived> won't
work!
};

class A : public Abstract {
public:
void func() const { cout << "A" << endl; }
};

class B : public Abstract {
public:
void func() const { cout << "B" << endl; }
};

int main()
{
Caller c(new A);
c.func();
c.set_x(new B);
c.func();
return 0;
}

with an Abstract non-virtual d~tor (or the compiler generated equivalent):

A
~Abstract
B
~Abstract

.... memory leak ... ~A and ~B are never invoked

with Abstract virtual d~tor:

A
~A
~Abstract
B
~B
~Abstract

.... ok ...

[forayer]

david wrote:

He is probably not allowed to modify A and B. If he could, then I don't
see why you would need a Caller class at all.
You're right, if that's the case then it doesnt.
Well, i hope you realize you are passing a pointer to an object you have
not created and then you are deleting it in the destructor.

Where am I doing that??? As far as I can see, I am just passing a base
class pointer, which could very well be pointing to a derived class
object. besides, i do check if it is a null pointer before deleting the
object pointed to.
Could you clarify your statement, please?

forayer

[david]

Sorry, i understand my english is bad, i'll make an effort:

Caller(Abstract *x) { this->x = x; }
void set_x(Abstract *x) these are two ways of initializing a Caller object. You are passing as
parameters an Abstract object that someone else created. ~Caller() { if(x) delete x; }

In the above destructor you are deleting the object pointed by x, but of
course you don't know wether it's a shared object, and you are deleting
it, so you are imposing through your particular implementation that just
the object Caller may use the object pointed by x and no one else. This,
for example, wouldn't be valid:

void do_bad_things (Abstract * a) {
Caller caller ( a );
caller.func ();
.... // more things
} <<<< After returning, the object pointed by "a" has been deleted.

This would be better:
~Caller() { }

[forayer]

david wrote:

> Caller(Abstract *x) { this->x = x; }
> void set_x(Abstract *x)

these are two ways of initializing a Caller object. You are passing as
parameters an Abstract object that someone else created.

Well, I am passing only a pointer to the object. Besides, whatever
object the passed pointer points to has to be a derived class object of
class Abstract (since class Abstract is, well, abstract!). I figured
that since:
Abstract *x = new A;
x->func();
x = new B;
x->func();
is valid, I could use the same technique in class Caller. Of course,
this makes sense only if class Caller is made use of as a class
factory.

> ~Caller() { if(x) delete x; }

In the above destructor you are deleting the object pointed by x, but of
course you don't know wether it's a shared object, and you are deleting
it, so you are imposing through your particular implementation that just
the object Caller may use the object pointed by x and no one else.

I agree. But if you take a look at the main() function in the first
post by Jason Heyes, you will see that the Derived<A> object is left
dangling when Derived<B> is created and assigned. So I thought a little
cleanup action might tidy up such things.

rgds,
forayer

[Peter Julian]

"forayer" <th********@hot mail.com> wrote in message
news:11******** **************@ g47g2000cwa.goo glegroups.com.. .

david wrote:

I agree. But if you take a look at the main() function in the first
post by Jason Heyes, you will see that the Derived<A> object is left
dangling when Derived<B> is created and assigned. So I thought a little
cleanup action might tidy up such things.

And you dangled both since:

~Caller() { if(x) delete x; }

only deletes the Abstract portion of the derived class (x is a base pointer
and Abstract doesn't have a virtual d~tor).