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

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

Quote:

---

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.).

Quote:

---

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.

Quote:

---

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

Quote:

---

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

Quote:

---

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"?

Quote:

---

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

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.

Quote:

---

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.

Quote:

---

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

Quote:

---

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

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