1

First question :)

Basically I would like to achief multiple Form inheritance in a .NET WinForms project.

We work with a Framework that has 2 base classes: UIForm and UIWizard. We are (unfortunately:) forced to use those forms to start our own implementations.

On top of those we have built the following structure: UIForm is superclass of OurForm. UIWizard is superclass of OurWizard. OurForm and OurWizard are pretty much twins.
OurForm in itself is also the superclass for other forms: OurCrudBase, OurListBase, OurSearchBase, ...

The opportunity
OurForm and OurWizard contain "dossier"-related properties and methods while this dossier-context is not relevant for many forms. To make things worse, we have recently started adding forms that have entirely new contexts: The existing Dossier but also Client, Statistic etc.

So here it is
We want a Form that is both CrudBase and DossierBase. Or a form that is ListBase and ClientBase etc. To achieve this with single inheritance, the amount of base forms would explode (ie DossierBase + CrudBase + ListBase etc etc). So we don't want to do that.

The solution
We are looking into deleting the UIForm by saying that a UIForm is in fact a UIWizard but with just "one step". The amount of BaseClasses would already be halved by that.

The Base classes can actually be divided into two categories
- Functional: Dossier, Client, Statistic, ...
- Technical: Crud, List, Search, ...

UIForm would become the superclass of either the technical or functional forms. The other type would be implemented as Strategies.

Functional Derived classes:
+ A form can only possibly be one of the functional classes. A form cannot be made for both "stastics" and for "client". In that way inheritance makes sense here.
+ Implementing the technical functionality as strategies is probably possible. I was thinking an interface that basically had a method for everything that can happen on the form: Load, Save, Closing, Closed, ...
- Interaction between the different strategies would probably be messy. (ie making sure that when you put both List and Crud to a form that the implementations don't screw eachother)

Technical Derived classes:
+ Somehow I have a better feeling with this approach. (Even though I can only list negative points)
- Once again you need duplicate classes when you want to combine for example List+Crud. The amount of duplication is minimal however.
- There is no common ground for Client, Dossier, Statistic. So turning them into a strategy is rather difficult.

I think I already pretty much answered my own question. But do you agree? Or do you think I'm overthinking this and should I just put as much as acceptable in the superclasses and do as little inheritance as possible?
Or perhaps an entirely different approach to tackle the problem?

Any help will be most appreciated!

Cheers,
Wouter

Laoujin
  • 11
  • 2
  • Multiple inheritance is arguably a bad thing. In my experience, form inheritance is usually a *very* bad thing. I can't start to imagine the nightmare it would be to have multiple form inheritance... – Thomas Levesque Dec 06 '10 at 17:31

1 Answers1

3

Based on your description, I don't quite understand why you need inheritance at all. Seems like you might be better off using composition instead of inheritance.

I would suggest that you create components, controls, and code templates to handle the different issues then you can just drag in what you need. You can have just a single base form that overrides the methods/properties that you need overridden and provide an easy way (such as raising events) for your components/controls to do whatever custom work they need to do with them.

Brian
  • 37,399
  • 24
  • 94
  • 109
  • Thanks! I'll look into that. Quick reference on inheritance vs composition: http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance – Laoujin Dec 06 '10 at 17:31