The Move to Object-Oriented Programming
As Visual Basic evolved, some object-oriented capabilities were added along the way, and arguments raged about whether the lack of this or that feature made Visual Basic less than a “pure” object-oriented language. Well, no more. Visual Basic .NET has emerged as a first-class player in the .NET arena. While Visual Basic .NET has taken its place among the pantheon of purely object-oriented languages (as are all languages that .NET supports), the story of how we got here has its share of ironic twists.
You’re obviously reading this book not only to learn how to use the intrinsic Windows and ASP.NET controls in Visual Basic .NET more effectively but also to find out how to build your own custom controls using object-oriented programming. There are many reasons—almost all of them valid—why Visual Basic has evolved over the years to finally become purely object oriented. But we’re not using classes, inheritance, polymorphism, and encapsulation just because object-oriented programming (OOP) is the be-all and end-all of paradigms. While OOP is compelling and a productivity enhancer, consider that this methodology has been in the mainstream for over two decades. Until recently, however, OOP never really reached the critical mass of programmers required to become the default way to write applications. After all, it’s difficult to argue with the 3.5 million classic Visual Basic programmers whose language wasn’t object oriented yet who continued to build world-class programs. These Visual Basic devotees made classic (non-OOP) Visual Basic the most popular language on the planet for building new programs.
If we examine Visual Basic’s meteoric rise in popularity, we see that even though classic Visual Basic wasn’t a pure OOP language, many parts of Visual Basic were actually much more reusable than those written in “pure” OOP languages. Not only that, it was still easier and faster to develop applications using Visual Basic than any competing language. In short, classic Visual Basic accomplished what OOP languages promised but never fulfilled in a large scale: true reusability. So how did we all make this giant step to pure OOP? I think this revolution happened largely because of one feature: controls. Let me explain.
Ironically, it was non-object-oriented Visual Basic that was ultimately responsible for bringing OOP to most programmers. For over 30 years, programmers were hearing about the dire straits of programming. Programs were getting too complex. There were not enough good programmers to go around. Large projects were constantly behind schedule and over budget, and many were canceled because they collapsed under their own weight. OOP emerged from academia and promised to help U.S. businesses with code reusability. In the mid-1980s, C++ made its debut, with the siren song of code reusability—the Holy Grail of programming. Unfortunately, in practice this was not to be for the mainstream of program development for several reasons.
In corporate development circles in the 1970s and 1980s, every time a certain piece of code was required, such as a calendar function, a programmer would typically write it from scratch. This approach was obviously costly and time-consuming. All the mainstream computer literature in the mid-1980s cited the object-oriented approach of C++ as the silver bullet for software development. A programmer would be able to write a functional calendar object once, and when this common object was needed in the next programming project, the coder could simply plug the coded and tested object into the next project.
In 1986, Cox and Novobilski coined the term Software-IC (Integrated Circuit) in the first edition of their book Object Oriented Programming: An Evolutionary Approach. Their idea was that just as you plug in a chip on a circuit board, you could plug in a software object, such as a calendar, in an application and build from there. It sounded too good to be true, and unfortunately it was in many cases.
Today when we think of OOP, we think reusability. However, this was not always the case. For example, in 1987, Bjarne Stoustrup (the inventor of C++) and Brad Cox (the inventor of Objective-C) debated the problem of large-scale component exchange. When pressed, both men agreed that the appropriate scope for reuse of C++ modules was probably at the project or even the departmental level, certainly not the plug and play first envisioned for the application level.
So what went wrong? Typically, what would happen in the real world is that a programmer would initially write a calendar object, and that tested and debugged object would be given to the next team for a new project. Instead of reusing that object, however, the new team would say something like, “Hmm, you know we need to have all holidays show up in red. We also need a feature that will alert us to all holidays.” The original calendar object didn’t have these features, so the programmers would inherit the original control and add the functionality needed to the object for that particular project. This inevitably meant inheriting from the original object, adding additional functionality, and thereby creating a new and different object. This new object required performing another round of regression testing, writing new documentation, and so forth. Although you could argue that if the original designers had completely thought out the original calendar, refining it wouldn’t have been an issue. However, the cycle of revisions and retesting often occurred with each new project. Because of this kind of tinkering, the ultimate goal of code reusability inside a corporation was never achieved in practice on any wide scale. While the Microsoft Foundation Class Library (MFC) greatly assisted in the process for C++, all of the above issues still generally applied.
Another problem was that learning to program in C++ was just flat out difficult. A decent programmer needed at least four to six months just to become functional in the language and another six months to become productive. Good C++ programmers were both scarce and expensive. Many other programmers tried and failed to grasp the abstract language.
Providing application programmers with controls such as text boxes for entering strings was a mind-bending idea when it debuted in Windows 1.0 in 1985. From the outside, things haven’t changed much. A button in .NET looks very much like a button from almost 20 years ago. But the original controls were child controls that communicated with their container via Windows messages, which proved unwieldy because not enough was hidden from the programmer. When the Visual Basic 1.0 16-bit VBX controls were unveiled at the 1991 Windows World conference in Atlanta, they were immediately seen as simple to use and took the software development community by storm. Not only was this new language several orders of magnitude easier to learn than C++, but it was also fun to program with. But the real reason Visual Basic wowed the programming world when it debuted was because the software contained 16 (16-bit) VBX controls that shipped with the product. Now you could draw a text box on a form, set some properties, and have a working Windows program.
Soon Windows morphed from 16 bits to 32 bits, and the controls switched from VBX to OLE custom controls. Microsoft marketing thought the name OLE was too geeky and not sexy enough, so the controls were rechristened ActiveX. ActiveX controls felt and smelled like VBX controls, but under the hood everything was based on the component object model (COM). The difficulty of writing these ActiveX controls was inversely proportional to their ease of use. The Windows operating system didn’t have any plumbing for these, and everything had to be written from scratch. And since COM didn’t support inheritance, there was a built-in dead end. Developers couldn’t extend the functionality—they had to make do with what was provided.
The original 16 VBX controls were off-the-shelf components that shipped with Visual Basic version 1.0, and they allowed developers to write real applications in a hurry. Writing a program quickly in C++ was an oxymoron. Although C++ is object oriented, it also involves complex concepts that programmers have to understand: not only classes and objects, but also Windows internals, message loops, and memory management. Visual Basic developers would have none of that. They could easily create applications by arranging a few controls on a form, edit the control’s properties, and write surprisingly few lines of code to complete a useful and working program. C++ programmers took time out from wrestling with pointers and memory leaks to scoff at Visual Basic programmers because they were using a “toy language.”
As it turned out, for many projects Visual Basic was better than C++, for a variety of reasons. Visual Basic operated at a much higher (and consequently more abstracted) level than C++. In C++, you had to completely define a form, which included setting style bits, and then register it with Windows. In Visual Basic, the form was just there by default.
When all is said and done, the whole purpose of OOP is to make programming easier and allow the developer to be more productive. If something makes your work easier, you should usually use it. If it makes your life more complicated, you should avoid it because in the long run it will ultimately cost you considerably more than not using it. Although C++ was compiled and therefore sometimes ran faster than the interpreted Visual Basic, the incremental increase in hardware speed over time ultimately made this point moot. And third-party plug-in controls were available to take care of the things that couldn’t be accomplished in Visual Basic.
Another irony is that the very 16 controls that made Visual Basic 1.0 a superstar had to be written in C++ or C because Visual Basic just didn’t have the capability. But these controls could then be hosted in a Visual Basic form. Many Visual Basic programmers learned C++ just so they could author controls.
As we know, OOP rests on the three-legged stool of inheritance, polymorphism, and encapsulation. Inside the controls this was true. But when a Visual Basic programmer drew a control on a form, it was quickly noted that to the user the control only provided encapsulation. The control was a black box of functionality—its implementation was completely hidden to the outside world.
For example, a button control was born knowing how to respond to a mouse click and a mouse-over. The programmer simply wrote code against these events. Bringing up the property box permitted the programmer to set the button’s caption property. It was the 16-bit VBX Controls that permitted Visual Basic programmers to be immediately productive—usually orders of magnitude more productive than the best C++ programmer. The single leg of the OOP stool, encapsulation, ignited the controls market.
Download
Another .NET Books
Another Visual Basic Books
No comments:
Post a Comment