When you are learning to build software, at first every program is its own problem, and every solution looks different.
With more experience you begin feel the similarities between problems - they are not quite the same but part of the route to a solution seem to be the same, and you sense that there are underlying patterns
Abstraction is the process of recognising these patterns (and sometimes the more general patterns behind the patterns). We do this by learning to strip away inessential detail layer by layer and find the real nub of the problem.
If we learn to recognise these patterns, then we are already a long way towards building a solution using methods that we know will work. Design mistakes are less likely because the way is familiar and we will probably achieve our aims much more quickly. (When we are trying to learn our way around a new city trying to use new short cuts often makes us late because we are more likely to miss the way. It is better to construct our route plan using mainly the same familiar streets and large thoroughfares where we are unlikely to go wrong.)
We probably need some examples to fix this concept.
 |
 |
The classic London Underground map is a good example of abstraction. When we travel the underground what we really need to know is the order in which stations come along the line on which we travel, and where we can change lines. The exact geographical route followed by the line is not important (after all, we cannot even see out of the carriage). Nor do we need to know anything the distance between stations - we can only get off at stations. Hence, the modern Underground map - an example from 1977 is shown on the right above - is an abstraction of reality, just retaining the information that we really need to know in order to solve our problem of getting from A to B. (Compare this with the first version on the left.) The simplification actually makes it easier to plan journeys, because we are not distracted by inessential information. (This map may, of course, be completely useless for different problems, such as locating tunnel ventilation shafts on the surface.)
Incidentally, the example of the Underground map shows that visual designers understand and make use of abstractions. It could be said that most of visual art is really about selecting the right abstractions. (Choice of medium, quality of line, technique of drawing - all these are methods of abstracting something from the visual field in front of our eyes to convey the information that the artist considered most important.)
Let us now turn to computing.
Sorting collections into some type or order is a frequent problem in computing: it often a precursor to searching for matches. A fair fraction of the world's computing time is probably taken up by sorting and searching, so fast-running algorithms are important. The problem could be sorting people in order of height, age, national insurance number or name alphabetical order. You might have to do some of this in a database of 60 million people and a good algorithm could be a million times faster than a bad algorithm. It is even more important if you want to search a billion Web pages.
In some of these searches we are handling decimal numbers, in others integers, in other cases words, yet the underlying problem is always the same: given two objects if we have some sort rule that tells us which comes before the other we can sort a complete collection into an order, and we can in principle use the same efficient sorting algorithms for all sorting problems.
Now closer to home, some of the galleries developed on this site contain images constructed by tracing an underlying curve (perhaps a Lissajous figure). At regular points along the curve we pause and draw a motif (a wavy line). All the images in the Lissajous gallery are very different but clearly share some similarities. In fact, the underlying pattern is based on several types of abstraction:
- Following a curve
- Drawing a motif
- Cyclic manipulating of colour and opacity.
As we followed the development of this idea, the abstractions (trace a curve, draw a motif, get the colour) were eventually embodied in the code as subprograms - the process of decomposing the algorithm into different parts. This helps in two ways: firstly it is easier comprehend what the program is supposed to be doing if we describe it in terms of these abstractions, and secondly it is easier to see that the code as written is actually doing what we want to it to do. Furthermore, if we wish to develop the idea further (for example, working with different types of motif, or different types of curve) we will find it easy to modify the program because all the algorithms that implement each abstraction are together in one place.
This was a rather trivial and only slightly abstract example. Major software constructions (such as your Windows/Linux/MacOS operating system) are based around multiple layers of interconnecting abstractions. It would be impossible to build such systems - millions of times bigger than those we will write - without systematic and effective use of abstraction.
The Processing system itself is based around multiple layers of abstraction. These are just a few of the ideas involved:
- Processing is a layer software running on top of Java. Java runs on top of Windows (or Linux or the Mac OS). The OS layer runs on top of the computer hardware.
- Processing is a toolkit: (or perhaps a Lego kit) a collection of items that can be assembled or used together in many different ways to achieve aims that are not themselves explicitly part of the design intent of this software layer.
- Processing sketches are constructed from objects like points, lines, ellipses, rectangles and so on. These are abstractions that get implemented as patterns of pixels on a computer screen.
Effective problem solving (whatever the domain) tends to come down to working with abstractions and so being able to see similarities with previously solved problems, and so being able to exploit what worked before. In many fields (e.g. politics or business) the fundamental abstractions are rather loosely defined (freedom, sovereignty, free trade, customer focus). They still allow politicians and business men and women to solve their problem.
A 1994 "Design Patterns" book caused an explosion of awareness in the software world, but of course architects, craftsmen, landscape designers and artist were there long before. (E.g. Chippendale's "The gentleman and cabinet-maker's director".) The software "patterns" movement was strongly influenced by the seminal architectural Pattern Language book by the architect Christopher Alexander and it figures as recommended reading on some software engineering courses. There have also been influences from patterns in nature (as explored by D'Arcy Wentworth Thomson in "On Growth and Form"). It is arguable, however, that the discipline of computer science has now developed the concept to an exceptional degree of formal precision and practical effectiveness.
Although modern computer science is closely related to disciplines such as electronic engineering, it is often taught as a branch of applied mathematics, and practical programming is only a part of what students have to master. Much of what they do is learning how to exploit abstraction.