Joseph is the first to take up the challenge and reply to my post about extender providers vs. sub-classing. Joseph points out that there were three reasons for using sub-classing that were discussed internally:
- A place to make “global” changes to the behaviour of an item (change style to “flat”, fix memory leaks or rendering problems).
- Create an “adapter” to reduce the surface area of complex controls, make the API more familiar.
- Remove coupling between application and underlying tool-kit (allowing you to potentially swap something else in if the first one doesn’t cut it).
Sub-classing has one advantage over extender providers in that by using the derived-class you automatically get the modified behaviour when you drag the control onto the design surface for the first time – with an extender provider you have to drag it on before it can start affecting other components on the design surface.
Having said that, I find the first point to be pretty weak. I’ve seldom had to sub-class in order to fix a memory leak or a rendering problem, in most cases memory leaks and rendering problems come from home grown GDI code which can be fixed at the source.
That leaves using sub-classes to support global styling of controls which I really don’t have an argument against other than to say if you are having trouble getting your developers to use styles consistently what chance do you have of getting them to use a sub-classed control consistently. In fact this is just the kind of thing that should be defined in a spec and caught during a rigourous and repeatable testing process.
The adapter argument (point 2) is an interesting one. I would point out that there is commonality between all the controls in Windows Forms in that they all derive (ultimately) from the Control base-class. From there, the APIs diverge in different directions because each control is so different – is it possible that the common features have already been factored down into base classes?
Truth be told, I suspect that any adapterizing (is that a word) of controls that does go on is probably around areas like security, validation and databinding than visual elements, unless you project is heading for a way out there look and feel.
In both the ASP.NET and the Windows Forms space I’ve seen quite a few frameworks been built out of an adaption layer. And while the idea is good in theory, in practice it ends up knobbling developers
Extender providers represent a middle of the road approach (even if I’m quite militant about it) to dealing with things like security, validation and databinding where each “aspect” (just forget the stigma for a few moments) is seperated out into its own provider or set of providers and associated components.
Developers learn to use the standard windows controls plus and third party widgets and then just have one place to look (providers) for each of the different aspects they want to have in their application.
The third point is probably hard to argue. Extender providers don’t allow you to switch the components out by changing a base class – but as Joseph pointed out I’m not terribly convinced that this a must have in your architecture anyway.
Hrm – maybe we should have a bakecode-off to see who can implement a relatively complex screen’s (multiple different controls) security and validation requirements using each approach.