Comments on Steve's Personal Blog: Form inheritance in Visual Studio 2005

Not quite. "is-a" vs. "has-a" is a trite catch-all...

2007-02-11T14:36:00.000-04:00

Not quite. "is-a" vs. "has-a" is a trite catch-all rule for composition vs. inheritance, but in fact, composition is largely viewed as a better technique over inheritance for anything but the most trivial object models. GUI models are absolutely non-trivial. With inheritance you run into problems with conflicting base-classes especially in C++ (the "diamond" problem). All problems of multiple inheritance can be solved with composition. In this particular case, your problem would go away since the designer *could* create an instance of the class in question. The problem would be that you would have to delegate about 50+ methods that belong to the Window base-class. A Facet pattern (or even a Decorator pattern) would fix this problem much better, but obviously M$ still hasn't chosen a good object model for their GUI. You could probably handle this easily by using introspection and creating a dynamic proxy object for methods that you don't want to override. Actually, wouldn't the C# "delegate" option do this for you?

Generally, the .Net framework does tend to favour ...

2007-02-09T18:34:00.000-04:00

Generally, the .Net framework does tend to favour composition over inheritance, but the Forms and WebForms are the exception - as Steve says they lend themselves to inheritance much more readily.

I agree that it would be nice to mark the abstract bases as abstract. As I understand it, this is due to the fact that the designer actually instantiates an instance of your form at design time. In fact, if you have a bunch of initialization in your constructor, you can actually end up with unwanted state saved in your form definition. Ugghh.

Another similar thing that drives me nuts is that XmlSerializable classes must have a default constructor whether this is appropriate for the design or not. But that's another story...

Ah, the old "is a" vs. "has a" conundrum. You can...

2007-02-09T16:57:00.000-04:00

Ah, the old "is a" vs. "has a" conundrum. You can't really use composition effectively when you're dealing with dialogs. You don't really want a dialog that "has" or "contains" another type of dialog, you want it to *be* that type of dialog.

When a class becomes more tangible and has a visible portion such as a dialog or a window, the "has a" metaphor doesn't apply as easily.

It's all about the polymorphism for me ;)

Prefer Composition over Inheritance.

2007-02-09T16:41:00.000-04:00

Prefer Composition over Inheritance.