256 Part IV: Dealing with Data Structures

The Problem with Software

No matter how powerful a computer is, the software that controls it limits its power. The biggest problem with software is reliability. Reliability means that software works without crashing, freezing up, or acting erratically. Software reliability is especially critical with real-time systems, such as airplane navigation systems, computers that host corporate Web sites, and financial trading programs, where losing a single number can mean the loss of billions of dollars.

Of course, reliable software is useless if you can’t write it in time. Because of the conflicting demands that companies and programmers finish software on time and make sure that it works reliably, most rush their software out before they can fully test it (which means that it probably doesn’t work right), or they delay the software so long that people switch to a competing product. (And those who wait still have no guarantee that the software’s going to work correctly, even if it’s several years late.)

Whatever fancy new technology, programming language, or programming style may appear, software always faces the twin challenge of working right while reaching users as quickly as possible. This situation means that all software is likely to contain bugs that keep it from working as efficiently as possible.

Ways to Make Programming Easier

In the early days of computers, most programs were fairly small. As a result, programmers often wrote programs with little planning and organization. After finishing the program, they’d run it to see whether it worked. If it didn’t work, they simply rewrote the program and tried again.

Such a trial-and-error approach worked fine for writing small programs, but after programs became larger and more complex, rewriting the program over and over made programming tedious and error-prone. The larger the program, the more places bugs could hide, making the program more likely not to work at all.

With today’s programs often consisting of a million or more lines of code, the trial-and-error method of writing programs no longer works. Writing a large program without planning or organization is like trying to build a skyscraper without blueprints.

Chapter 19: Playing with Object-Oriented Programming 257

Programmers adopted a new strategy. Instead of trying to write one huge program, they decided to write a bunch of little programs (known as subprograms).

The idea was that small programs are easier to write and debug, so you just need to write a bunch of small programs, paste them together, and end up with a larger program that works reliably, as shown in Figure 19-1.

Although the idea of writing small subprograms and pasting them together like building blocks was a sound idea, problems still existed. You may divide a large program into smaller subprograms, but the instructions that you store in one subprogram can still manipulate data that another subprogram uses, as shown in Figure 19-2.

To solve this problem (and solving problems is something that programmers continually strive to do), programmers developed the idea of isolating subprograms in separately compiled files. In this way, subprograms can’t mess around with each other’s data, and yet they can still work together to create one larger program.

Taking the idea of isolating subprograms into separate and isolated parts (known as modules in programming lingo), programmers eventually developed the idea for objects and, hence, the term object-oriented programming.

Figure 19-1:
Breaking a
large
program
into smaller
subpro-
grams can
make
programs	One huge continuous program	A large program divided into
easier to
write.		several subprograms