What does abstraction mean in programming?

Solution 1:

Abstraction is a core concept in all of computer science. Without abstraction, we would still be programming in machine code or worse not have computers in the first place. So IMHO that's a really good question.

What is abstraction

Abstracting something means to give names to things, so that the name captures the core of what a function or a whole program does.

One example is given in the book you reference, where it says

Suppose we’re working with turtles, and a common operation we need is to draw squares. “Draw a square” is an abstraction, or a mental chunk, of a number of smaller steps. So let’s write a function to capture the pattern of this “building block”:

Forget about the turtles for a moment and just think of drawing a square. If I tell you to draw a square (on paper), you immediately know what to do:

draw a square => draw a rectangle with all sides of the same length.

You can do this without further questions because you know by heart what a square is, without me telling you step by step. Here, the word square is the abstraction of "draw a rectangle with all sides of the same length".

Abstractions run deep

But wait, how do you know what a rectangle is? Well, that's another abstraction for the following:

rectangle => draw two lines parallel to each other, of the same length, and then add another two parallel lines perpendicular to the other two lines, again of the same length but possibly of different length than the first two.

Of course it goes on and on - lines, parallel, perpendicular, connecting are all abstractions of well-known concepts.

Now, imagine each time you want a rectangle or a square to be drawn you have to give the full definition of a rectangle, or explain lines, parallel lines, perpendicular lines and connecting lines -- it would take far too long to do so.

The real power of abstraction

That's the first power of abstractions: they make talking and getting things done much easier.

The second power of abstractions comes from the nice property of composability: once you have defined abstractions, you can compose two or more abstractions to form a new, larger abstraction: say you are tired of drawing squares, but you really want to draw a house. Assume we have already defined the triangle, so then we can define:

house => draw a square with a triangle on top of it

Next, you want a village:

village => draw multiple houses next to each other

Oh wait, we want a city -- and we have a new concept street:

city => draw many villages close to each other, fill empty spaces with more houses, but leave room for streets
street => (some definition of street)

and so on...

How does this all apply to programmming?

If in the course of planning your program (a process known as analysis and design), you find good abstractions to the problem you are trying to solve, your programs become shorter, hence easier to write and - maybe more importantly - easier to read. The way to do this is to try and grasp the major concepts that define your problems -- as in the (simplified) example of drawing a house, this was squares and triangles, to draw a village it was houses.

In programming, we define abstractions as functions (and some other constructs like classes and modules, but let's focus on functions for now). A function essentially names a set of single statements, so a function essentially is an abstraction -- see the examples in your book for details.

The beauty of it all

In programming, abstractions can make or break productivity. That's why often times, commonly used functions are collected into libraries which can be reused by others. This means you don't have to worry about the details, you only need to understand how to use the ready-made abstractions. Obviously that should make things easier for you, so you can work faster and thus be more productive:

Example:

Imagine there is a graphics library called "nicepic" that contains pre-defined functions for all abstractions discussed above: rectangles, squares, triangles, house, village.

Say you want to create a program based on the above abstractions that paints a nice picture of a house, all you have to write is this:

import nicepic
draw_house()

So that's just two lines of code to get something much more elaborate. Isn't that just wonderful?

Hope this helps.

Solution 2:

A great way to understand abstraction is through abstract classes.

Say we are writing a program which models a house. The house is going to have several different rooms, which we will represent as objects. We define a class for a Bathroom, Kitchen, Living Room, Dining Room, etc.

However, all of these are Rooms, and thus share several properties (# of doors/windows, square feet, etc.) BUT, a Room can never exist on it's own...it's always going to be some type of room.

It then makes sense to create an abstract class called Room, which will contain the properties all rooms share, and then have the classes of Kitchen, Living Room, etc, inherit the abstract class Room.

The concept of a room is abstract and only exists in our head, because any room that actually exists isn't just a room; it's a bedroom or a living room or a classroom.

We want our code to thus represent our "mental chunking". It makes everything a lot neater and easier to deal with.

Solution 3:

As defined on wikipedia: Abstraction_(computer_science)

Abstraction tries to factor out details from a common pattern so that programmers can work close to the level of human thought, leaving out details which matter in practice, but are not exigent to the problem being solved.

Basically it is removing the details of the problem. For example, to draw a square requires several steps, but I just want a function that draws a square.

Solution 4:

Let's say you write a function which receives a bunch of text as parameter, then reads credentials in a config file, then connects to a SMTP server using those credentials and sends a mail using that text.

The function should be named sendMail(text), not parseTextReadCredentialsInFileConnectToSmtpThenSend(text) because it is more easy to represent what it does this way, to yourself and when presenting the API to coworkers or users... even though the 2nd name is more accurate, the first is a better abstraction.

Solution 5:

The best way to to describe something is to use examples:

A function is nothing more than a series of commands to get stuff done. Basically you can organize a chunk of code that does a single thing. That single thing can get re-used over and over and over through your program.

Now that your function does this thing, you should name it so that it's instantly identifiable as to what it does. Once you have named it you can re-use it all over the place by simply calling it's name.

def bark():
  print "woof!"

Then to use that function you can just do something like:

bark();

What happens if we wanted this to bark 4 times? Well you could write bark(); 4 times.

bark();
bark();
bark();
bark();

Or you could modify your function to accept some type of input, to change how it works.

def bark(times):
    i=0
    while i < times:
        i = i + 1
        print "woof"

Then we could just call it once:

bark(4);

When we start talking about Object Oriented Programming (OOP) abstraction means something different. You'll discover that part later :)