Volume Number: 14 (1998)
Issue Number: 6
Column Tag: Viewpoint
by Nicholas C. "nick.c" DeMello <editor@mactech.com>
Creating great software requires an odd mixture of humility and arrogance. The art of programming involves studying complex behaviors, accomplishing them with efficient logical processes, and expressing that logic so simply and clearly that even a machine can enact it. For someone to consider teaching a hunk of silicon the skill of piloting an airplane, the subtleties of quantum mechanics, or even the simple trick of announcing "hello world"... well, a little arrogant confidence is required. But the best among us temper their confidence with the realization that there is no profit in reinventing the wheel, that we can never foresee all the possible applications of our product, and that bugs happen. The outrageous confidence needed to try something untried and the necessary caution required to turn that something into reliable and efficient code is epitomized by the Mac OS and the modular, extendible program design underlying it. In this issue, MacTech presents a number of articles on modular software design and plug-in technologies. I want to introduce just a few of them here.
It's been estimated that the Lisa project, the precursor of today's Macintosh, took over 200 man years to accomplish. Lisa owed significantly to ground breaking work in the design of the WIMP (windows, icons, mouse, pointer) GUI developed at Xerox. While the WIMP development at Xerox's Palo Alto research center (PARC) was occurring, the term "object-oriented" was being coined in the same facility. PARC developed the Smalltalk language - arguably the purest representation of the object-oriented ideal - at the same time they were working on the WIMP interface. The influence of object oriented design on Xerox's GUI is clear. That same influence affected Lisa and is an integral part of today's Mac OS.
The Macintosh operating system was broken down into a multitude of smaller, simpler goals. Many of these objectives are represented by independent code modules or runtime libraries. By breaking projects down into simple, self-contained and independently compiled objects bugs are isolated and easier to locate, while project goals become clearer and easier to define. It also makes your project adaptable and expandable. Consider all the powerful technologies, never dreamed of by the Lisa engineers, that have been added to the Macintosh operating system.
Your next project may not be as intimidating as writing a new operating system, but then it might feel that way. You probably will apply a modular design to that project, breaking the code down into smaller and more manageable pieces represented by different classes or code files. But, what if you took that a step farther and isolated fundamental logic to a separately compiled removable, replaceable plug-in? Not only would your next update be a little easier, your code base and bug space a little smaller, but I bet you've already started thinking about entirely different logic you could offer as a second plug-in. Rest assured, if you haven't - one of your users will. In this issue, Joe Zobkiw describes the fundamentals of adding a plug-in architecture to your next application. By providing a plug-in architecture you, or your more creative customers, can expand and adapt your product in new and exciting directions.
Or consider the problem from the other side. Perhaps your goal can best be achieved by creating new logic for an existing application. Tools like Resorcerer, FileMaker Pro, Netscape and CodeWarrior offer plug-in architectures and therefore opportunities to tune these powerful tools to your most specific needs. They also offer opportunities in that you can quickly create valuable companion products for existing markets. Photoshop is an essential tool for graphic artists, establishing a huge market for plug-in companion products like Kai's Power Tools and Alien Skin's Eye Candy. To get an idea of how easy it can be to create a plug-in, take a look at Steve Sheets article in this issue on crafting plug-ins for BBEdit - the Swiss army chainsaw of text editors.
Modular design isn't only about plug-ins. Most programmers have a folder someplace. That folder is filled with snippets and example code (a class for implementing a preferences file, a linked list code module, or just a snippet showing how to spin a cursor). Odds are you don't even read most of that code anymore, it's just copy and paste - plug and play. That's the way it should be. Detroit doesn't reinvent the wheel every time they build a new car and we don't need to reinvent Mercutio every time we want to create dynamic menus.
Ramon Felciano's Mercutio MDEF is just one example of elegant and powerful reusable code. Another is the SpriteWorld library. SpriteWorld let's you drop a wealth of powerful and intuitive graphics code right into your application. In this issue Stefan Sinclair explores SpriteWorld libraries and shows you the fundamentals of introducing spectacular effects into your next program. Are you curious what other mechanisms there are for incorporating libraries into your Macintosh programs or offering libraries to other developers? Jeremy Nelson's article provides a concise overview of the possibilities.
The technologies and opportunities for plug-in products and precompiled libraries on the Macintosh are varied and quietly growing. We hope that some of the information you find in this issue will help you to explore and profit from those opportunities. Enjoy!in this issue will help you to explore and profit from plug-ins. Enjoy!
