Until recently, programs were thought of as a series of procedures that acted upon data. A procedure, or function, is a set of specific in...
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:
- Find out what each person earns.
- Count how many people you have.
- Total all the salaries.
- Divide the total by the number of people you have.
Totaling the salaries can be broken down into
- Get each employee's record..
- Access the salary.
- Add the salary to the running total.
- Get the next employee's record.
In turn, obtaining each employee's record can be broken down into
- Open the file of employees.
- Go to the correct record.
- 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 functionality.
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.