Abstraction
Page 1
Abstraction
The example of a candy bar dispensing machine that we gave before could serve as a design for someone who actually wanted to build such a machine. Somehow the builder would need to build into the machine some kind of memory that could remember each state of the machine (i.e., how much money had been inserted up to this point). How might that be done? Fortunately, we don't care. That's one of the benefits of being a designer...the designer doesn't care how the design is actually implemented in hardware as long as it works (ok, some designers do care, be we aren't one of them).
In fact there are lots of things missing from the design candy bar dispenser. How is change returned? How is the dispensing mechanism triggered when the correct amount of money is inserted? What happens if the machine is empty? What if someone wants a refund before a pop is dispensed? What if the user doesn't like Coke? The answer to all of these questions is simple. We don't care. Ah, but the life of a theoretician is indeed simple at times. The theoretician's creed is: "I don't care."
When we say that we don't care, that doesn't mean that we are uncaring people. What it does mean is that we don't care about the particular details of the object we are studying right now, but rather, in general, what the intrinsic properties of such machines are. This is the process of abstraction, and it is used in mathematics all of the time. Instead of worrying about one kind of machine, such as a candy bar dispenser, we look at the underlying principles of all such machines and create a model with generic features that apply to them all. Then we can study the model to see what its capabilities and limitations are.
