| Excerpts from "Building Internet Applications..." |  |
|
Table of Contents
Chapter 2 COM
Chapter 4 Builtin controls
Chapter 5: Using COM objects
Chapter 6 Logistics
Chapter 7 Distributed Programming
Chapter 8 Server-side programming
Chapter 9 Installation and Signing
Chapter 10 Stupid Windows Tricks
Chapter 11 Conclusion
First and foremost, this is a book about components. Using components, developing components, combining components, finding components. Component-based programming is an extremely efficient way of developing complex applications. And the best thing about it is that Windows is already chock full of powerful components just waiting to be re-used. Re-use is truly the holy grail of software development but the latest component development techniques have begun to make it a realizeable goal. In 1985, Brad Cox was one of the first to envision the concept of "software IC's" that could be purchased and easily integrated together, perhaps on a "software board". He went from there to object-oriented programming which produces source-level components, but the idea of re-useable components becomes most useful at a binary level. This is where today's standards, like Java Beans and ActiveX controls really start to make a difference. HTML pages and "layout controls" can be viewed as the "board" into which components can be "plugged in". And scripting code becomes the "wiring" to hook up the components. It saddens me to see a whole crop of new Windows programmers who only know Windows through MFC. Windows is a wonderful, sometimes quirky operating system and MFC covers it all up with a big, fat, ugly library. The good news is that MFC hides the ugliness of Windows (under its own ugliness!). The bad news is that MFC hides the elegance of Windows (under its own ugliness). I've met too many MFC programmers who don't understand the difference between MFC and Windows and it's difficult to break them out of their MFC cocoons to see that using COM objects within HTML or VB is lower in overhead, lower in learning curve time, and faster to develop. What's particularly ironic is that about 6 years ago, when MFC was the only game in town and I was trying to convince managers and developers to use MFC instead of writing directly to Windows, I was told that MFC was too much of a toy for "commercial" applications. Now, I'm hearing that same excuse for not writing in HTML / JScript / ATL! COM objects can be programmed through MFC, but MFC's implementation of COM is ugly - utilizing nested class declarations and macros, macros, macros. I'll have more on this in Chapter 3, Building COM objects, and I'll also discuss implmenting COM with ATL. ATL is based on C++ templates (with a few macros thrown in) and it lets you get build simple, elegant, close-to-the-metal, COM objects easily. I wouldn't want to build a COM control host, though - that's where the bulkiness of MFC comes in handy. MFC implements enough of the features of Internet Explorer to act as a COM control container. Although Internet Explorer includes a lot of other features that would be difficult and annoying to write in MFC. In chapter 1, I discuss my philosophy of programming, "Zen-gineering". This is the art and science of implementing features without writing code. MFC is about as anti-Zen-gineering as anything could be, requiring mountains of code to do the simplest tasks. Of course, if job security is your goal (along with long schedules and hours of debugging), maybe MFC is the environment of choice. I've been there. I got out. Save yourself! A few years ago, I coined the term Zen-gineering which meant the implementation of features without coding or through removal of code. This may seem like a contradiction in terms and in reality, it's more of an axiom than a methodology. That being the best way to implement a feature is without coding it. Less code means less bugs, less to maintain, less work to add additional functionality. There are many ways that zengineering can be done -- using a browser as an application framework is one of the best. |
|