MFC Considered Harmful to Programmers
Windows programming is difficult. Windows class libraries make Windows programming easier. True or false?
bool IsWinProgEasier (Method method)
{
if (method == WIN_CLASS_LIBRARIES)
return false;
else
return true;
}
Seriously, if all you want is to write programs that are exactly like the creators of MFC or OWL figured out you would, and you don't care about the overhead, then using class libraries and application wizards is the way to go. But any time you want to step outside of this path, you'll find yourself in deep trouble.
Let me give you an analogy. Imagine that you're buying a set of Lego blocks. You can buy a general purpose set, or you can buy a specialized set for building a pirate ship. If all you want to do is to build a pirate ship, the second choice is superior. But if you try to build a Lego car, you'll have to overcome a few problems. Eventually you'll come up with something that resembles a car, but it will have a funny steering wheel, use an anchor for breaking, and the driver will have a stick leg and a black patch over his eye.
After working with this Pirate Lego set for a while, you will become a specialist in building almost anything that could be built with a general purpose set. You'll learn all the tricks-- like how to remove the patch from the pirate's eye, how to paint over the skull and crossbones, etc. Eventually you'll reach a point when the amount of knowledge you've assimilated about the Pirate set will be much more than the basic engineering principles you'd have to learn in order to use general purpose Lego. From that point on, you'll be throwing good money after bad money, investing in more and more sophisticated (and complicated) Pirate sets.
What should you do? My advice is-- cut your losses short and start learning Windows programming now. The Windows API is not a thing of beauty or simplicity-- that's why all these class libraries became so popular in the first place. But if you want to grow beautiful flowers, you'll have to get your hands dirty. As far as object programming and Windows go, I don't want you to reinvent the wheel. There are some simple OO techniques that will help you encapsulate the ugly face of Windows API.
As a side effect, you'll be able to produce Windows programs that are small enough to be easily downloadable over the Internet. Small programs also load very fast--they don't need any of the bulky MFC dlls. I challenge any MFC fan to write a Battleship game that's smaller than ours, yet offers the same functionality.
Let's start our tour of Win32 API with the simplest possible Windows program...Hello Windows!.
There is an excellent article by Ellen Ullman, The Dumbing-Down of Programming, that should be a recommended reading for everyone who still feels any residual urge to use MFC or OWL. It's available online:
or, in paper form, in August 89' edition of Harper's magazine. Here are a few quotes:
"In this programming world, the writing of my code has moved away from being the central task to become a set of appendages to the entire Microsoft system structure."
"Why study all the complicated code that the wizards generate for me since it already works anyway?"
"The temptation never to know what underlies that ease is overwhelming. It is like the relaxing passivity of television, the calming blankness when a theater goes dark: it's the sweet allure of being a user."
If you're a fan of object-oriented programming, you might find this quotation from the MFC's official Guidelines for Writing Class Library Extensions pretty amusing.
Limit the Use of "Private" in Your Classes It is important that your users be able to use your MFC-friendly classes in ways that you might not have originally intended. By keeping the majority of
member functions, data members, and operators public, you allow for flexibility in their use. In MFC, even functions declared in the //Implementation section of a class are usually public or protected.
Recommended reading:
Brent E. Rector, Joseph M. Newcomer, Win32 Programming, Addison-Wesley
A very thorough and detailed presentation of Win32 API. Excellent reference.
And here's the feedback from one of our visitors, Dave Linenberg.
I've spent about 20 minutes perusing your web site, and I really enjoyed your views on programming -- especially those concerning the bloated nature of MFC. I couldn't agree with your observations more.
I first played around with writing Windows programs using the API in 1991/1992 (I learned from Petzold's first book)...and then with all the talk of object oriented software, I tried learning MFC. I read through
Prosise's book, and worked through all the exercises. I traced through a couple hundred pages of MFC source code, and stumbled into a lot of undocumented stuff. I got MFC Internals. I was determined to really
understand MFC....I never did. It was pretty sickening. The MFC which was supposed to make things simple, is extremely complex. Spending 1 year with the raw API, and coupling that with some good object oriented
paradigms/patterns and C++ books like those by Eckel or Meyers will get you much farther than trying to tackle MFC. Everybody thinks that writing 5 lines of code in MFC or some framework to create a window is
better or easier than learning the API. I would agree only if the framework is completely understood - because those 5 lines are hooked into thousands of lines of code, with little ability of doing much more
than small scale SDI/MDI book example programs.
Why couldn't Microsoft encapsulate the C orientation efficiently. Why all the overhead?
First I was enamored with document/view -- I never knew what a "pattern" was -- and with MFC, this was my first encounter. As my programs became a jumble of cyclic physical dependencies, I realized this doc/view paradigm that MFC was forcing me into was terrible - at least in their implementation of it!! Ever notice that
example programs are very small in books. Most books never touch on how to implement large sets of interacting classes (other than Lakos book, Large scale C++ Software design) What if I had a large program
with, a 1000 views, and a 1000 documents, all inter-related -- all passing messages. What if it were multi-threaded/distributed.... What a mess that would be using MFC doc/view. What a joke!
More feedback.
|
