int, object-oriented methods, etc. For this purpose, however, we need a short preamble in which we will briefly trace the way in which some software abstractions evolved and paved the way for the advent of the next Object-Oriented level of abstraction.
             When we come to think of it, we will see that any language can be viewed as an abstraction. For example Assembly language is a small abstraction of the underlying machine. It was in its turn abstracted in many high-level languages, the so-called "imperative" languages such as Fortran, BASIC, and C. These languages were great improvements over Assembly language, but their primary abstraction still required you to think in terms of the structure of the computer rather than the structure of the problem you were trying to solve. The programmer had to establish the association between the machine model (in the "solution space," which was the place where you were modeling that problem, such as a computer) and the model of the problem that was actually being solved (in the "problem space," which was the place where the problem existed). The effort required to perform this mapping, and the fact that it was not inherent to the programming language, produced programs that were difficult to write and expensive to maintain.
             The object oriented approach cures most of the ailments of the "imperative" approach by going a step further, providing tools for the programmer to represent elements in the problem space. This representation is general enough so that the programmer is not constrained to any particular type of problem. We refer to the elements in the problem space and their representations in the solution space as "objects." (Of course, you will also need other objects that don't have problem-space analogs.) The idea is that the program is allowed to adapt itself to the lingo of the problem by adding new types of objects, so when you re...