Chris rant reminded me about something I thought of in regards of the Windows Forms design.
A lot of the Winforms technology is cool. Many controls are easy to use, and things like the way layout works with docking and anchoring is really cool and useful. However, if you look at the larger picture of the Winforms library design, you'll realize a large portion of it sucks.
Why? Chris already mentioned part of it indirectly in his rant: Too much of it relies on base classes to work. Why didn't they rely more on well defined interfaces instead of base classes?
Much of this leads to what I consider really weird looking class hierarchies. For example, the familiar concept of a "window" is pretty well hidden underneath the whole framework. As for the Control base class... can it suck more? It makes no sense to me to have the concept of a Form be an instance of the Control abstraction. I consider them to be fundamentally different things because their usage model is, overall, too different. Instead, I would've liked to see the Window abstraction as a base pattern, with Forms and Controls being two separate abstractions built on top of it.
And while on the subject: Form? Blagh!
Likewise, one could argue against several other Winforms abstractions and particularly agains conventions.... why does the Control class offer like 7 different ways to take a control's position and size, with only some of them being directly updatable? Hell, why couldn't we have only one or two? Is there no consistency and simplicity in our world anymore?
I don't do much Winforms coding these days, but I did quite a bit before. I always found it weird that at times I was missing MFC so much, and that's even though I haven't written a single line of MFC code in like three years!
4 Comments
archived from WordPress — closedMy experience is exactly opposite: Most of the work I do is low-level, and every once in a while I need to write some GUI code. In my experience, writing UI in C#/WinForms is about 10% of the effort required by C++/MFC. This is despite my knowing C++ far better than C#, or having worked in MFC a lot longer than WinForms. Perhaps when you try to create your own controls it's different -- but for me, WinForms is sufficient reason to write all my little utilities in C#.
I don't argue otherwise. What I argue about is that the large scale design of windows forms could've been better. It has way too many leaky abstractions, if you know what I mean.
And you'll notice them once you try to do any real complex UI in windows forms, I think.
This brings up an interesting question: Is there a good design that would support both?
Is other words, do you see (or know of) a good design that would please devs like me -- who rarely do UI work and need simple abstractions --yet also support people like you, who obviously need the power to do complex work?
IMHO, it is sometimes very difficult to achieve this in a single API. In some cases I know of, the results were the design of two separated interfaces. This, of course, also sucks.
Oh, sure there is Ziv.
Designs that hide low-level details in interfaces are not harder to use than class-heavy designs. And they are significantly easier to extend.
The problem is that most people don't know the principles of good OO design. For a good start, read the six articles linked from the Robert C. Martin section of the following page: http://www.jelovic.com/misc/people.htm
Dejan