Re: Simple OO design issue
On Jun 1, 4:07 pm, Naresh Rautela <nraut...@gmail.com> wrote:
On Jun 1, 2:39 am, Stuart Redmann <DerTop...@web.de> wrote:
obrianpatr...@gmail.com wrote:
Hi,
I am relatively new to object oriented programming and design. I am
developing an application in VS 2005. I am having the following design
problem:
I have two interfaces X and Y. Y is derived from X as the following:
__interface X
{
public:
virtual void func1(int) = 0;
};
__interface Y: public X
{
public:
virtual void func2(int) = 0;
};
Common scenario.
X interface is implemented in the class XImpl as follow:
class XImpl: public X
{
public:
void func1(int i)
{
cout << "In XImpl::func 1: i = " << i;
}
};
Okay.
Now I want to have a class YImpl implementing func2() of Y interface.
func1 implementation should remain the same as in XImpl. How should I
define the class YImpl? Deriving it only from Y interface, as
class YImpl: public Y
will not allow me to use the func1() implementation of XImpl. I have
to rewrite the same function in YImpl then.
On the other hand inheriting YImpl multiply from XImpl and Y as
as
class YImpl: public XImpl, public Y
How should the class YImpl be defined and implemented? Please note
......
You have stumbled over some implementation issues that come together with
interface programming (when using some component architecture). The standard
solution to your problem is to make the implementation class XImpl a template:
template<class t_BaseInterface>
class XImpl : public t_BaseInterface
{
public:
void func1(int i)
{
// Implementation of func1 of interface X
}
};
Cool!!! Thats a very cool way of doing it. However, I have a feeling
that whenever you run in to such issues and have to resort to such
geeky way of doing things, it points to a design issue. Probably the
interface is not being used the way it was intended to be. Probably
we need a composition here rather than a inheritance (Class Z embeds
both class X and Y). Would really appreciate if someone out there
points out a scenario where such a construct is an absolute must.
Well this is standard com issue, except that he should specify
__stdcall calling convention to produce valid COM objects.
For example, this is also perfectly legal way of doing it:
__interface X
{
void __stdcall func1(int);
};
__interface Y: X
{
void __stdcall func2(int);
};
struct XImpl
{
void* vptr;
int j;
static void __stdcall func1(XImpl*x,int i)
{
cout << "In XImpl::func 1: i = " << i;
x->j = i;
}
};
struct YImpl
{
XImpl x;
YImpl();
static void __stdcall func2(YImpl*y,int i)
{
cout << "In YImpl::func 2: i = " << i << " j = " << y->x.j;
}
};
typedef void (__stdcall *func_t)(YImpl*,int);
struct YImplVtable{
func_t func1,func2;
}vty = { (func_t)&XImpl::func1,&YImpl::func2 };
YImpl::YImpl(){x.vptr=&vty;}
and in program:
YImpl ii;
Y* y = (Y*)ⅈ
y->func1(42);
y->func2(1);
Actually laying down objects and vtables is only way to
program COM objects in C. If C++ provides layout
compatibility it has convenient syntax.
Interfaces just provide vtable layout, can't be used for
casual C++ programming (no virtual destructors so user must
provide function for deletition, only public
non virtual inheritance allowed ...)
Greetings, Branimir.