Mix and match class in C++/MFC

I'm trying to re-factor a code base, and there is some开发者_高级运维 common functionality among unrelated classes that I'd love to unite. I would like to add that functionality in common base class, but I'm not sure if it's clean and good approach.

Say I have CMyWnd class and CMyDialogEx class, both different, so they cannot inherit from one base class. I want to add a button to both classes and add the message handlers to both classes as well.

So I'd like to do something like this:

CMyWnd : public CWnd, public COnOkBtnFunctionality, public COnCancelBtnFunctionality
CMyDialogEx: public CWnd, public COnOkBtnFunctionality

Where COnOkBtnFunctionality would define CButton m_buttonOk, and all the afx_msg functions it should have. And so on.

Is this approach doable/good? Or are there better patterns I should resort to?

---

You're experiencing problems because of the design of COnOkBtnFunctionality, which wants you to use inheritance just for code reuse.

A quick reminder: Inheritance is not designed for code reuse, it's designed for introducing abstraction.

Or in other words: Is your CMyWnd a specific kind of COnOkBtnFunctionality, or does it have COnOkBtnFunctionality?

Let me redirect you to Jeff Attwood for some more on the topic: http://www.codinghorror.com/blog/2004/08/inherits-nothing.html

---

Basically you're wanting to use multiple superclassing to implement the Mixin functionality. Such implementation has some merits, but also drawbacks.

Consider how you can implement COnOkBtnFunctionality and family so that they will be expected to be used as components, not superclasses of your a Window class. It's certainly possible and you're likely to like the result.

Alternatively, one thing I can recommend you to consider is the Decorator pattern, which may possibly be exactly what you need. It has the advantage that the "extensions" may be chosen and applied selectively in runtime easily.

---

Haven't done much MFC in years, but from a purely OO perspective, this smacks of bad design. You should look at composition, in reality both windows own instances of a button - why the heck would you derive from it? Let's say for argument's sake you now implement more types of buttons, do you intend to derive from all of them?

---

Inheritance (or public inheritance at least) defines a is-a relationship. Is your window a button functionality? Or does your window have a button functionality? Obviously it's the latter, so I suggest to go for composition (or maybe private inheritance - see this FAQ article).

---

Composition would be the right design decision; do not inherit.

If you have a special type of button that can be reused, create one: class MyButton : public CButton

If MyButton need access to methods from CMyDialogEx and CMyWnd, extract the common methods in a virtual class (strategy pattern) and derive from it. You can use the MyButton's constructor to place the instance of virtual class, so MyButton's methods can access the real implementation.

I can recommend Alan's and James's book Design Patterns explained -- A new perspective on object-oriented design (ISBN-13: 978-0321247148):

It's a great book about has-a and is-a decissions, including cohesion and coupling in object-oriented design.