B
Bonj
Hello
Can anyone assist with the following class hierarcy problem?
I have a series of window classes, the object model currently being as such:
Window
/ | \
/ | \
MDIClientWindow | TreeViewWindow
WndProcWindow
/ \
/ \
DualPaneWindow SplitterWindow
i.e., the base class is Window. It has three direct subclasses,
MDIClientWindow, WndProcWindow, and TreeViewWindow. WndProcWindow also has
two further classes deriving from it, DualPaneWindow and SplitterWindow.
(MDIClient- and TreeView- don't have their own WndProcs)
Now, I am having the following problem: I want to create a few pure virtual
methods on the base Window class, in order that I can create a function that
will take a Window* and call a certain method on a [Something]Window,
knowing that it will have it - e.g. Create()=0. This will make Window a pure
abstract class, this is fine. However, I have been scratching my head as to
the best way to implement this, because WndProcWindow is already an abstract
class - it has a pure virtual method, WndProc.
I'd like to make Window an abstract class, with some methods e.g. Create(),
as pure virtual methods. But this would mean that WndProcWindow would have
to implement them, and it wouldn't be appropriate for it to. Is there any
neat way of getting around this, like some way of telling the compiler that
WndProcWindow won't actually implement the Size method, but any
instantiatable class deriving from it must, because it also derives from
Window?
e.g.
// (Window.h)
void Create(LPCTSTR class, DWORD style);
{
....(generic CreateWindow code here)
}
void Create() = 0; // ???
//WndProcWindow.h
LRESULT WndProc(...) = 0;
void Create(LPCTSTR, DWORD);
void Create(); // ???
//SplitterWindow.cpp
SplitterWindow::Create()
{
WndProcWindow::Create(RegisterClass(... "splitterclass", ...), WS_CHILD |
WS_VISIBLE);
}
//TreeViewWindow.cpp
TreeViewWindow::Create()
{
WndProcWindow::Create(WC_TREEVIEW, WS_CHILD | WS_VISIBLE);
}
//WndProcWindow.cpp
WndProcWindow::Create(LPCTSTR class, DWORD style)
{
Window::Create(class, style);
}
WndProcWindow::Create() //??? help! what goes here?....
{
}
I thought of one solution - multiple inheritance. This would solve it - as I
could have an abstract class, say CreatableWindow, that had the pure virtual
methods e.g. Size(...) = 0, and then DualPane-, MDIClient-, TreeView- and
SplitterWindow could all multiply inherit from WndProcWindow or Window, and
then CreatableWindow aswell. But I've heard horror stories about multiple
inheritance - and that MS says it's one of those "if you really must"
things. A hunch tells me a multiply-inheriting class is like an inbred. Is
my hunch right, will it slow down my code or lead to spaghetti code without
any real benefit, or is it a little-discovered, rarely used technology
that's perfect for this kind of scenario?
On this particular project the porting to other compilers isn't a problem as
I've used loads of VS specific features anyway, but I would like to know if
it is to be avoided or not? Is it a performance hit?
Thanks for any guidance on how to accomplish the above or suggestions on how
I can better structure this without ripping the design apart completely! (It
seems good apart from this...)
(I hope this doesn't seem irrelevant to c.l.c++ as it's really about classes
not windows...)
Can anyone assist with the following class hierarcy problem?
I have a series of window classes, the object model currently being as such:
Window
/ | \
/ | \
MDIClientWindow | TreeViewWindow
WndProcWindow
/ \
/ \
DualPaneWindow SplitterWindow
i.e., the base class is Window. It has three direct subclasses,
MDIClientWindow, WndProcWindow, and TreeViewWindow. WndProcWindow also has
two further classes deriving from it, DualPaneWindow and SplitterWindow.
(MDIClient- and TreeView- don't have their own WndProcs)
Now, I am having the following problem: I want to create a few pure virtual
methods on the base Window class, in order that I can create a function that
will take a Window* and call a certain method on a [Something]Window,
knowing that it will have it - e.g. Create()=0. This will make Window a pure
abstract class, this is fine. However, I have been scratching my head as to
the best way to implement this, because WndProcWindow is already an abstract
class - it has a pure virtual method, WndProc.
I'd like to make Window an abstract class, with some methods e.g. Create(),
as pure virtual methods. But this would mean that WndProcWindow would have
to implement them, and it wouldn't be appropriate for it to. Is there any
neat way of getting around this, like some way of telling the compiler that
WndProcWindow won't actually implement the Size method, but any
instantiatable class deriving from it must, because it also derives from
Window?
e.g.
// (Window.h)
void Create(LPCTSTR class, DWORD style);
{
....(generic CreateWindow code here)
}
void Create() = 0; // ???
//WndProcWindow.h
LRESULT WndProc(...) = 0;
void Create(LPCTSTR, DWORD);
void Create(); // ???
//SplitterWindow.cpp
SplitterWindow::Create()
{
WndProcWindow::Create(RegisterClass(... "splitterclass", ...), WS_CHILD |
WS_VISIBLE);
}
//TreeViewWindow.cpp
TreeViewWindow::Create()
{
WndProcWindow::Create(WC_TREEVIEW, WS_CHILD | WS_VISIBLE);
}
//WndProcWindow.cpp
WndProcWindow::Create(LPCTSTR class, DWORD style)
{
Window::Create(class, style);
}
WndProcWindow::Create() //??? help! what goes here?....
{
}
I thought of one solution - multiple inheritance. This would solve it - as I
could have an abstract class, say CreatableWindow, that had the pure virtual
methods e.g. Size(...) = 0, and then DualPane-, MDIClient-, TreeView- and
SplitterWindow could all multiply inherit from WndProcWindow or Window, and
then CreatableWindow aswell. But I've heard horror stories about multiple
inheritance - and that MS says it's one of those "if you really must"
things. A hunch tells me a multiply-inheriting class is like an inbred. Is
my hunch right, will it slow down my code or lead to spaghetti code without
any real benefit, or is it a little-discovered, rarely used technology
that's perfect for this kind of scenario?
On this particular project the porting to other compilers isn't a problem as
I've used loads of VS specific features anyway, but I would like to know if
it is to be avoided or not? Is it a performance hit?
Thanks for any guidance on how to accomplish the above or suggestions on how
I can better structure this without ripping the design apart completely! (It
seems good apart from this...)
(I hope this doesn't seem irrelevant to c.l.c++ as it's really about classes
not windows...)