Until recently, programs were thought of as a series of procedures that acted
upon data. A procedure, or function, is a set of specific instructions executed
one after the other. The data was quite separate from the procedures, and the
trick in programming was to keep track of which functions called which other
functions, and what data was changed. To make sense of this potentially
confusing situation, structured programming was created.
The principle idea behind structured programming is as simple as the idea of
divide and conquer. A computer program can be thought of as consisting of a set
of tasks. Any task that is too complex to be described simply would be broken
down into a set of smaller component tasks, until the tasks were sufficiently
small and self-contained enough that they were easily understood.
As an example, computing the average salary of every employee of a company is
a rather complex task. You can, however, break it down into these subtasks:
- 1. Find out what each person earns.
2. Count how many people you have.
3. Total all the salaries.
4. Divide the total by the number of people you have.
Totaling the salaries can be broken down into
- 1. Get each employee's record.
2. Access the salary.
3. Add the salary to the running total.
4. Get the next employee's record.
In turn, obtaining each employee's record can be broken down into
- 1. Open the file of employees.
2. Go to the correct record.
3. Read the data from disk.
Structured programming remains an enormously successful approach for dealing
with complex problems. By the late 1980s, however, some of the deficiencies of
structured programing had became all too clear.
First, it is natural to think of your data (employee records, for example)
and what you can do with your data (sort, edit, and so on) as related ideas.
Second, programmers found themselves constantly reinventing new solutions to
old problems. This is often called "reinventing the wheel," and is the
opposite of reusability. The idea behind reusability is to build components that
have known properties, and then to be able to plug them into your program as you
need them. This is modeled after the hardware world--when an engineer needs a
new transistor, she doesn't usually invent one, she goes to the big bin of
transistors and finds one that works the way she needs it to, or perhaps
modifies it. There was no similar option for a software engineer.
New Term: The way we are now
using computers--with menus and buttons and windows--fosters a more
interactive, event-driven approach to computer programming. Event-driven
means that an event happens--the user presses a button or chooses from a
menu--and the program must respond. Programs are becoming increasingly
interactive, and it has became important to design for that kind of
Old-fashioned programs forced the user to proceed step-by-step through a
series of screens. Modern event-driven programs present all the choices at once
and respond to the user's actions.
Object-oriented programming attempts to respond to these needs, providing
techniques for managing enormous complexity, achieving reuse of software
components, and coupling data with the tasks that manipulate that data.
The essence of object-oriented programming is to treat data and the
procedures that act upon the data as a single "object"--a
self-contained entity with an identity and certain characteristics of its own.