1.1 Revolutionists, Evolutionists, and the Object-Oriented Paradigm

In the process of learning about the object-oriented paradigm and all that it encompasses, you will first become aware of the many divisions within our community. Each division implies two or more camps who are generally very religious about their point of view. One of the first divisions of importance is the revolutionists versus the evolutionists. The revolutionists believe that a group of developers woke up at 3 o'clock one morning and realized that we have been developing software the wrong way all along. They believe they have found the solution to the software crisis, and the name of that solution is object-oriented programming. As the reader may have surmised, I fall into the camp of the evolutionists.

The evolutionists feel that object-oriented programming is no revolution in software development. It is simply the next logical step in a long series of steps that take the software developer further and further away from the machine details. A software crisis does not come about because we are incorrectly developing software. A software crisis comes about because our paradigm of programming is no longer sufficient to handle the complexity of problems we are asked to solve. Using octal and/or hexadecimal opcodes to write programs is a great paradigm when there are only 8 instructions and 1K of memory in our machine, of which 90 percent is used up by our operating system. I have no trouble using this method of programming when there are only 8 opcodes to remember and 30 lines of code to write. When my hardware becomes more sophisticated and I begin getting problems that require 64K of memory, remembering opcodes then starts creating a level of complexity I cannot handle. At that time, I begin using assembly-language mnemonics. This works great until a point where the complexity of my problems outgrows this paradigm. I similarly upgrade to using a high-level language whose instructions each replace many assembly-language mnemonics, allowing me to think at a higher level. Aside from reducing the language complexity, I also seek out a better way of thinking about my problem. Instead of stringing instructions into small functions and small functions into programs, I use a structured method for breaking my problem into smaller pieces, each of which is manageable.

We are currently at a point in software development where structured, top-down design methods are no longer sufficient for handling the complexity of problems possible with today's hardware. We need to find a paradigm of software development that can handle the added complexity. Very recently—in 1985—menu-driven systems were the norm. Today, a software application must have a graphical user interface if it is to be marketable. Within the next few years, the consumer will demand multimedia applications that talk to them, listen to them, and display moving video across the screen. Why is the object-oriented paradigm generating so much interest as a method for handling these more complex applications?

One of the biggest reasons for moving to the object-oriented paradigm for developing complex applications is that it allows designers more closely to model the real world. What do we find in our day-to-day lives that, I am sure everyone agrees, can be very complex? We find many machines, which interact with each other in a very decentralized fashion. There is no central control mechanism to which everyone reports, gets orders, fulfills them, and returns for more work. Structured methods are built on the idea of centralized control. The strength of a decentralized architecture is the fact that any one problem will affect one area of the application, which, in a good design, will be loosely coupled to the other areas of the application. This limits the impact of change on our system should there be a problem with one application area, or should we wish to extend the same. If decentralization allows the real world, with all of its complexities, to operate, shouldn't we attempt to handle complex software problems in the same way?

The newcomer to object technology will face suggestions such as "Before you can truly be an object-oriented developer, you will have to undergo a paradigm shift." While this sounds a bit dramatic, there is a kernel of truth to the notion of a paradigm shift. The software developer needs to think in a decentralized fashion, rather than follow the typical centralized control of the structural approach. Since successful real-world entities interact in a decentralized manner, I argue that there is as much an unlearning curve as a learning curve. You are unlearning the centralized control on which you have learned to rely in the action-oriented model of software development.

Regardless of where you stand on the revolution/evolution argument of object-oriented programming, the first annoyance you will encounter in learning the object-oriented paradigm is the proliferation of buzzwords that permeates the field. For example, a fairly straightforward concept that we will discuss in this book is called polymorphism, which is a simple concept hidden behind a Greek root word. Add to this synonyms such as dynamic binding and runtime-type discrimination, and modifying adjectives such as pure polymorphism and true polymorphism, and one can easily get caught up in a web of confusion. The buzzword problem is common in young fields. It takes a considerable amount of time for a technology to mature to the point where it has captured its concepts in a standard vocabulary. The problem is compounded in the object-oriented field in that many different subfields within computer science are approaching the object paradigm with their own vocabulary. While one group may be perfectly happy talking about containment and inheritance relationships, another group may already be calling these concepts has-a and a-kind-of relationships (respectively). I suspect that this problem will stay with us for the near future but will become a nonissue as the field matures. In the interim, I will attempt to avoid the use of synonyms in this book unless they are truly necessary to emphasize a particular point to a user.