How to avoid parallel inheritance hierarchies among GUI controls and domain objects.

Question

I am developing a Windows Forms application in C#. I am using the MVP design pattern. In the GUI the user can manipulate printer objects, and there needs to be custom controls that represent the printer objects to the user.

There is a class hierarchy that represents the printers. At the base there is an abstract Printer class. Then there is an abstract InkJetPrinter class and an abstract LaserPrinter class, each inheriting from Printer. The concrete classes represent the different makes and models of printers and inherit from either InkJetPrinter or LaserPrinter.

Each UserControl class in the GUI that represents a printer needs to have features and functionality specific to the type of printer. For example, an ink jet printer might have a display that shows the ink level, a certain model of laser printer might have special features that could be accessed from an additional button on the control, etc.

I do not see a better way of handling this than to have an inheritance hierachy of UserControl classes parallel to the inheritance hierarchy of Printer classes. Is there a better approach?

Answer 1

In this design you probably need the LaserPrinterControl and InkJetPrinterControl, but they don't need to derive from a PrinterControl. For instance, you could both give both a "PrinterControl" child control.

The downside is a little more glue code, but the advantage is that you have complete control over the behavior of the PrinterControl.

Answer 2

I don't think this is a classic parallel inheritance hierarchy? If it were, then I think it would be required to write a GUI control class in order for the non-GUI printer classes to be fully functional. That is not the case since one could write a fully functional non-GUI application just using the printer classes and not the accompanying UserControl classes.