-
January 15th, 2012, 05:01 AM
#1
Class Design
Hello,
I have a question about my win32 class again, but this is not about stuff inside it. More about how I should work with class designs.
I create for instance a Dialog, it will go like this:
Code:
class Dialog : public Wintraits
class WinTrais: public WinFunc, public WinIcon, public WinBGround
The 'problem?' lies in WinTraits, there is my HWND stored, but all other classes need that specific HWND of the control to. So now I'm passing the HWND to Winfunc, WinIcon,WinBGround with a function, whenever the HWND of Wintraits is setted. I doubt this is the best way of doing this. So perhaps would this be a better solution:
Code:
class Dialog : public WinFunc
class WinFunc : public WinIcon
class WinIcon : public WinBGround
Class WinBGround : oublic WinTrats
Now I can store the HWND in Wintraits and then all other classes can use it. Is this ebtter, because it seems a bit weird to me?
Thanks for reading
Grz
-
January 15th, 2012, 10:39 AM
#2
Re: Class Design
the first one is a big no no and the second doesn't make sense.
Windows is Message-driven, with that in mind pick one that best suit your needs
Design Patterns
-
January 15th, 2012, 10:58 AM
#3
Re: Class Design
Originally Posted by NLscotty
I have a question about my win32 class again, but this is not about stuff inside it. More about how I should work with class designs.
A good guideline to follow is not to use inheritance for code reuse. The derivation of Dialog from Wintraits (by the way, why not just call it Window?) makes sense, because a dialog is a special kind of window. But a window is not necessarily a function, icon and background all-in-one. Rather, a window has a icon (well, some do), background, etc. This is better modeled using composition (i.e. Window has a member variable of type Icon, Background, etc.).
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
-
January 15th, 2012, 11:21 AM
#4
Re: Class Design
Originally Posted by D_Drmmr
The derivation of Dialog from Wintraits (by the way, why not just call it Window?) makes sense
no it doesn't
a type trait class is a tracer and tracing something works best decoupled from what it's supposed to trace or encapsulated for a single purpose. in term of class design, the only exception to this is probably the crtp pattern.
-
January 15th, 2012, 11:40 AM
#5
Re: Class Design
Originally Posted by NLscotty
Code:
class Dialog : public WinFunc
class WinFunc : public WinIcon
class WinIcon : public WinBGround
Class WinBGround : oublic WinTrats
As D_Drmmr mentioned, it looks like you're deriving classes from other classes only to save typing. That is not the way to use public inheritance.
The class hierarchy using public inheritance is supposed to model an IS-A relationship. A Windows function is not a Windows Icon, A Windows Icon is not a background, etc., so you should not be setting up your classes this way. In other words, the inheritance must make "real-world" sense.
Regards,
Paul McKenzie
-
January 15th, 2012, 05:35 PM
#6
Re: Class Design
Originally Posted by Paul McKenzie
As D_Drmmr mentioned, it looks like you're deriving classes from other classes only to save typing. That is not the way to use public inheritance.
The class hierarchy using public inheritance is supposed to model an IS-A relationship. A Windows function is not a Windows Icon, A Windows Icon is not a background, etc., so you should not be setting up your classes this way. In other words, the inheritance must make "real-world" sense.
Regards,
Paul McKenzie
Thanks this realy helped me in thinking. Also thanks to other posters of course.
In real life terms you could say: a Windows Icon is part of the Control/Dialog, same for the background and functions, right? It's like the Auto class, with wheels, a motor etcetc. Now the Car becomes a Control.
Also to do it all inside 1 class seems unaccrative, becuase there will be so many memebrs, that is becomes unreadable.
Grz
-
January 15th, 2012, 05:43 PM
#7
Re: Class Design
Also to do it all inside 1 class seems unaccrative, becuase there will be so many memebrs, that is becomes unreadable.
How many members do you consider to be "so many"?
In real life terms you could say: a Windows Icon is part of the Control/Dialog, same for the background and functions, right? It's like the Auto class, with wheels, a motor etc.
Then that becomes composition, not public inheritance.
Regards,
Paul McKenzie
-
January 16th, 2012, 05:17 AM
#8
Re: Class Design
This may or not be completely relevent to your problem, but the intention of your 'Wintraits' class may be a similar to something I developed a while ago.
In an MFC GUI extention library I was developing, I created a helper class that inherited from CWnd and added several functions to simplify the CWnd API and add some STL compatability. I wanted all of my new GUI objects to inherit from this, but as MFC GUI objects already inherit from CWnd, there was the 'Diamond problem'.
class TextBox : public Window, public CStatic
{
};
TextBox
^ ^
| |
Window CStatic
^
|
CWnd
My solution was the make the 'Window' class a template and force it to inherit from the template parameter type, thereby enforcing single inheritance.
termplate <typename T>
class Window : public T
{
};
class TextBox : public Window<CStatic>
{
};
TextBox
^
|
Window
^
|
CStatic
^
|
CWnd
Now, this is not the only way to solve this problem and many others may prefer an approach using composition. It would ultimately come down to the design requirements as to whether you wished functionality of the base object to be visible to users of derived classes. In my application, it was required that GUI objects could be seen as CWnd objects, and so inheritance was better suited to my needs.
"It doesn't matter how beautiful your theory is, it doesn't matter how smart you are. If it doesn't agree with experiment, it's wrong."
Richard P. Feynman
-
January 16th, 2012, 06:32 AM
#9
Re: Class Design
Originally Posted by potatoCode
a type trait class is a tracer and tracing something works best decoupled from what it's supposed to trace or encapsulated for a single purpose. in term of class design, the only exception to this is probably the crtp pattern.
Based on the OP's remark that Wintraits stores a HWND, I did not take this class to be a type traits class and suggested a change of the class name instead.
Cheers, D Drmmr
Please put [code][/code] tags around your code to preserve indentation and make it more readable.
As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky
-
January 20th, 2012, 05:34 PM
#10
Re: Class Design
Originally Posted by Paul McKenzie
How many members do you consider to be "so many"?
Then that becomes composition, not public inheritance.
Regards,
Paul McKenzie
For me a few hundered are quite a lot. And in that case I'll have all kind of Icon functions in my WinTraits class, isn't that wierd?
[CODE]
class wintraits..
...
private:
WinIcon* wIcon;
[/CODE[
If I wanna call a function from wIcon, I've to amek also a function in Wintraits which calls the function of WinIcon, or is it better to make WinIcon public, so everyone can acces it? That seems easier but not a good solution
Grz
-
January 20th, 2012, 08:39 PM
#11
Re: Class Design
Originally Posted by NLscotty
For me a few hundered are quite a lot.
Now the question is why there are a few hundred members for a Windows class.
All of the Windows API frameworks I've seen have nowhere near "hundreds" of members. Maybe there is something about your design that needs to be revisited.
NLScotty, there are just a few major ways of wrapping the Windows API into classes. Here are the few wrappers that exist:
- MFC -- single inheritance based.
ATL -- template based.
WTL -- template based.
Borland OWL -- usage of multiple inheritance to create windows
Windows++ -- not sure
http://www.relisoft.com/rswl.html -- see examples at the web site
There are others, but they are a mix of the ones above. Which one does your version mimic or is closest to in design? If none are, then maybe you should read up on how each of these accomplish the goal of wrapping the Windows API without introducing hundreds of members.
Regards,
Paul McKenzie
-
January 21st, 2012, 03:30 AM
#12
Re: Class Design
Sorry, I was not clear about hundred. I will add also functions for loading Icons etcetc. I did take a look at Qt and MFC to. Qt has even more members.
But still, if I want to have a QIcon class. I could make a function inWintraits and a variable in the WinTrait class and make the QIcon class change it? So that the user have to init a QIcon class itself? Or is it better to amek a private variable to QIcon and then make functions in the Wintraits class to call functions from it?
Grz
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|