inheritance problem

[Nico Massi]

i have a problem with my classes

i have a base class that defines the interface for a window ( abstract
class )
in a render device i have implemented the class for either Direct3D or
OpenGL
on the other hand i would implement the interface also for windows and
linux
my problem is now that the class WindowsWindow would inherit from the basic
window interface
but in runtime it must use either D3D or OGL window as base class( based on
the current render device )

so my class hierarchy would look like this

class window
{
/* data/interface here */
};

class windowGL : public window
{
};

class windowD3D : public window
{
};

class windowWindows : public window
{
};

the above hierarchy would work, but on runtime i need the window functions
of the windowWindows class for D3D or OGL based on the render device
( if it is a GL render device i would need the windowGL as base class,
otherwise windowD3D )

how can such a poblem solved?

[Thomas Matthews]

Nico Massi wrote:

i have a problem with my classes

i have a base class that defines the interface for a window ( abstract
class )
in a render device i have implemented the class for either Direct3D or
OpenGL
on the other hand i would implement the interface also for windows and
linux
my problem is now that the class WindowsWindow would inherit from the
basic window interface
but in runtime it must use either D3D or OGL window as base class( based
on the current render device )

so my class hierarchy would look like this

class window
{
/* data/interface here */
};

class windowGL : public window
{
};

class windowD3D : public window
{
};

class windowWindows : public window
{
};

the above hierarchy would work, but on runtime i need the window
functions of the windowWindows class for D3D or OGL based on the render
device
( if it is a GL render device i would need the windowGL as base class,
otherwise windowD3D )

how can such a poblem solved?

The issue can be resolved by abstracting as much of the common methods
into a generic class and only use the generic functionality.

There is no reason for inheritance since you will never have more
than one window type in a program. Factor this issue out of the
compiler and into the build system. Create a header file that
declares the class. Let the builder tool include the module
that has the definitions depending on the target platform.
--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.l earn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book

[White Wolf]

Nico Massi wrote:

i have a problem with my classes

i have a base class that defines the interface for a window ( abstract
class )
in a render device i have implemented the class for either Direct3D or
OpenGL
on the other hand i would implement the interface also for windows and
linux
my problem is now that the class WindowsWindow would inherit from the
basic window interface
but in runtime it must use either D3D or OGL window as base class(
based on the current render device ) [SNIP] the above hierarchy would work, but on runtime i need the window
functions of the windowWindows class for D3D or OGL based on the
render device ( if it is a GL render device i would need the windowGL
as base class, otherwise windowD3D )

how can such a poblem solved?

If you can separate OpenGL/D3D from Windows/Linux, I would suggest using the
Bridge pattern or something similar. If you cannot... I have no idea.

You could create a 3DService abstract class and a WindowingServic e abstract
class. Your final classes could use the services of those two, via a
pointer or reference. Those two could also access each other, but that
would introduce the chicken-egg problem. So if the concrete 3DService and
WindowingServic e should access each other, they have to do it via a 3rd
class.

Try not to use inhertiance, thrive for containment. Also - in your case
that seems to be possible - those things which would never change runtime
could be created using interface-equivalence instead of polimorphism.
Meaning that the classes would provide the same interface (same public
functions) but not inheriting from any common (abstract) base.

--
WW aka Attila

[Kevin Goodsell]

Nico Massi wrote:
<snip>

I don't mean to be rude, but I skip messages that don't bother to use
punctuation. If you want an answer to a question, it helps to make sure
the question can be understood, and easily read.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.