An audience at the Software Entrepreneurs' Forum/UniForum Open Systems Special Interest Group last week heard why and how object-oriented programming is being hailed as the next big advance in computing. (Also see the adjoining article on object environments.)
Bill Fairfield, a consultant with his own company, Fairfield & Co., in Oakley, CA, and an instructor at the University of California's Santa Cruz and Berkeley campuses, told the Palo Alto, CA, group first what's wrong with today's software. It's generally late being delivered, costs too much, and doesn't work very well, he said. In addition, "What's generally not recognized outside the software community is that software development is an extremely high-stress environment," and that contributes to the other problems, he said.
Fairfield's main emphasis for why software doesn't work was that the method for writing software has been forced on developers by the programming languages they use. In addition, he said the problems computing tries to solve are complex, poorly understood and poorly articulated; and neither managers nor computing customers can accurately gauge the scope of a project. Object programming can help, he said.
The first computer languages were assembly languages, which used mainly symbols. "These were good for basically nothing," Fairfield said. Then higher-level languages were developed that used English words and instructions executed in relation to modules of code. "We have stretched this as far as it will go," Fairfield said. "The problem is that this isn't the way people think. People think in terms of objects." The current problems being tackled by computers "are too complicated to be done in this rudimentary fashion."
To explain what he termed the "software crisis," Fairfield told of a study done by the military on the cost to fix a problem in a development program. To fix a problem in the design and test phase costs 10 times as much as in the requirements analysis phase. It costs 100 times as much in the production phase and 1,000 times as much once the completed system is in the field.
Object orientation works well for software for the same reason that it works for other engineering disciplines, he noted. In order to be solved, problems have to be decomposed-broken into component parts-and put back together. While most of today's programming deals with problems using functions, "Other engineering disciplines decompose problems by objects, not by functions. Objects will interact with one another to meet system requirements."
To illustrate how objects are used in programming, Fairfield used the example of a bank's automatic teller machine (ATM). The objects in programming an ATM could include the ATM itself, the user interface, the printer, the envelope slot, and the cash drawer. Each of these is considered a class of object. Both data and operations on the data are bundled into each object as a single entity.
"This simple change of bundling together the data and the operations into a single package solves some of the major problems of functional decomposition," Fairfield said. First, unanticipated changes can be made in data values, data storage types, and other variables by making them in one place. Thus, the programmer has simultaneous access to all data members. In addition, "You can make changes to the way data is stored without affecting the program."
Basic to object orientation is the notion of encapsulation-hiding data inside an object. "Encapsulation produces two views of each object-an outside view that shows what the object does and an inside view that shows how it works. Only the developers of an object need to see the inside view," Fairfield said.
To interact with the object, all the program-or another programmer employing the object-needs to have is the outside view. "It involves trust, which is completely alien to software engineering," Fairfield observed. When told to employ objects, traditional programmers always want to see the code first, he said. For that reason, not all traditional programmers may be able to transition to object orientation.
"The goal of object technology is to get the developers to deal with the interface and not the object itself," Fairfield said. That reduces complexity. "As an object-oriented programmer, I no longer need to know how the object itself works. I only need to know how to make it do what I want."
A programmer specifies objects at the level of the class, and all objects are grouped into classes. All the operations that can be performed on a class must be specified in the class itself, whether or not all the operations are actually employed on each instance of the class. In that way, "If you know how to work with one interface [in a class of objects], you know how to work with them all," Fairfield claimed.
In using the ATM example, each possible operation using the ATM must be programmed into the ATM class. Therefore, the operation "reject the card" must be included, even though a specific object may not employ it.
Values are added when objects are created. For example, "car" could be a class, with color, model, and price as values that are added when each object in that class is created.
Also fundamental to object orientation is the notion of inheritance of properties. The classes are ordered into hierarchies, with some classes having the status of superclass. Properties are then handed down from the superclasses to the classes beneath, so that if a superclass contains operations X and Y, all its classes have those operations. Thus, when changes are made to the program, the change can be made in only one class-only one place in the program-and the entire program will be fixed. That also reduces complexity, saves time, and prevents the kind of code proliferation that creates maintenance nightmares.
In traditional programming, "Code grows because for every change, the programmer has to go back to where he was before the change was introduced" and recreate a sequence of instructions, Fairfield said. That can produce more errors.
Another advantage of object orientation is that it creates a model of how the real world operates, and that model can then be used to solve other problems in its domain. As an example, Fairfield cited the way people solve the problem of finding their way in a strange city. The way traditional programming solves the problem is to give step-by-step directions leading from one starting point-a hotel, for instance-to a destination. That works as long as you always start and finish in the same place. And it doesn't allow for unforeseen problems such as road repairs. In Fairfield's view, object orientation is more like a road map. It creates a model containing objects such as streets and buildings and shows how they connect. The model can be easily reviewed for accuracy. It can be easily changed as conditions change. And it can be used in a variety of circumstances to solve a variety of problems.
The object-orientation process consists of four steps: scope the problem, considering all the external entities with which the system or domain interacts; identify the top-level objects; schedule the project; and iterate yourself through the programming cycle.
In identifying the top-level objects, it's best to write a summary of what the system is and what it does, then take the summary to the managers of the system for feedback. Ideally, five to nine objects should be selected as the highest-level objects in the system. Then, through considering a standard set of use cases, an event schema can be created for each possible use of the system. An event schema is good for only one use case.
Scheduling the project will involve incremental deliveries, Fairfield said, and each delivery must have software that fully meets some of the use cases. To achieve that, the use cases are bundled into releases and scheduled for a particular release. "What needs to be done in this phase is to take the objects and schedule them against the use cases they must satisfy. And it's good to get the user interface class in early because everyone will have an opinion." Then any suggested changes can be made early in the project.
Again in the ATM example, release 1 could contain only the ATM class. Release 2 could contain the ATM, the user interface, the printer and the reader. Release three could contain those classes plus the envelope slot and the cash drawer. "This type of schedule gives the manager time to give you his input on how the software is working under current conditions", Fairfield said. "About the worst feeling in the world is to get to the end of a project and deliver obsolete software."
In adopting object orientation, cost savings can't be achieved overnight, Fairfield warned, which makes it sometimes a hard sell to software developers. "Object-oriented programming has been sold as motherhood, apple pie, and all your software problems will be over," he said. "Developers don't believe it, and they shouldn't believe it." He recommended setting up and running several pilot programs and prototype projects to test the method, then writing a transition plan.
Developers should also remember that many objects have already been created and are available for free, Fairfield noted. The project team will need to test them and organize them into a hierarchy.
Object programming will probably cost more than traditional programming on the first two projects that a programming team tries, Fairfield said. In his experience, the best that can be expected on the first project is 28 percent above the usual cost. "Your second one is at best break even. But from the third on out, you're going to be making money on reuse of software."
On a particular military contract, one bidder-Magnavox-was able to reuse 386,000 lines of code of 1.8 million lines from another project. For that reason, other bidders were priced out.