MFC Best practice and modularity

Question

In MFC, certain mechanisms provided allow the programmer to bypass modularity and encapsulation and information hiding, arguable the most desirable features of an Object Oriented framework.

One (of many) examples is Owner Drawn controls: you can choose to either implement DrawItem in a child control subclass and do all of that control's drawing in that subclass, making it appear more modular:

class CustomButton: CButton{
     // --- Lots of stuff, DECLARE_DYNAMIC etc

     virtual void DrawItem(LPDRAWITEMSTRUCT lpdis){
          // Drawing code for this button in the button's subclass
     }
};

...or you can choose handle the WM_DRAWITEM message in a parent Window class via OnDrawItem

class MainFrame: CFrameWnd{
     // --- Lots of stuff, DECLARE_DYNAMIC etc

     CustomButton button; 

     afx_msg void OnDrawItem(LPDRAWITEMSTRUCT lpdis, UINT id){

          if(id == CUSTOM_BUTTON_ID){     
               // Drawing code for this button in the button's subclass
          }
     }
};

In the later situation, the drawing of the control is outside of the control subclass, meaning that the concept that "OOP data structures tend to carry their own operators around with them" is undermined.. right?

So my question is: which one is considered 'best practice'? There must be a reason that the second one exists - can anyone suggest a circumstance in which undermining modularity would be a better option?

Answer 1

This question seems to be asking when is it reasonable to have a parent object that contains one or more child objects to handle messages meant for the child rather than just passing the message on to the child letting the child handle it instead.

The specific example is with MFC window classes in which a window object that contains other window objects (button in this case) is processing a draw message rather than just passing the message on to the child to process.

The basic answer would be it depends. There may be cases where you are composing a window object and as part of that you are over riding the drawing behavior of child controls in order to change the look of the child controls. For instance if you have a set of buttons whose look you want to change based on information in the parent window, you may want to over ride the drawing of the child controls in order to change the appearance.

This would be similar to having a button object which allows multiple different types of looks by allowing a parent window to provide a drawing object to the child control. The result would be that the child would have a default drawing behavior which the parent would over ride by providing a drawing object.

See this article in wikipedia on the Strategy pattern or this article on Strategy pattern with side links for other patterns which provides a brief discussion on this sort of programming problem. Another example might be the Chain of Responsibility pattern.

In this specific example, rather than the parent providing a drawing description object to the child to use, the parent is instead just intercepting the drawing messages and doing the drawing itself.

If changing the look of a child control can be done without affecting the other functionality of the child control then this would not be a bad approach though it could be confusing to the programmer who is doing maintenance or other changes. However this kind of over riding behavior can be seen in other instances such as window clipping in which the drawing of some window component is clipped so that any part of the component that would be outside of the window area is not drawn.

So the approach of having the parent object intercept and handle messages targeting a child object of the parent provides a great deal of flexibility in allowing various parents to change a specific behavior of the child depending on what the parent is wanting to accomplish.

However this flexibility does have a price.

Answer 2

It would be suboptimal OOP if, in the second situation, CUSTOM_BUTTON_ID were some data used internally by the control. This would violate the concept of information hiding as defined by David Parnas (http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf). If the internal information changes, the parent window will be affected by the change and will itself need to be changed to match. This is how information hiding facilitates modularity; it keeps data bundled with the thing that needs it (and hides it from those that don't).

Based on comments this is a bad example, because there is no violation of information hiding going on, since CUSTOM_BUTTON_ID is actually data that is contained and used by the parent window, not the control. The drawing of the control is still done within the control; the parent window just calls the control's Draw method.