Abstraction means keeping the information you need to use a task while hiding the details you do not. Think of ordering an item online: you need to know what item to request and how many you want. You do not need to know whether a person or a robot finds it in the warehouse. section 20.1
To make a useful abstraction for a programming task:
- Break the larger job into smaller tasks. Notice which tasks depend on another task’s output and which can work independently. section 20.1
- For each task, identify its inputs, what it does, and its outputs. These are the facts someone needs to use it as a black box. section 20.2
- Write and test each task separately, then connect the pieces. A module can keep its own working details private and pass information to another module through outputs and inputs. section 20.2 section 20.3
Modularity and abstraction work together, but they are not the same thing. Modularity divides a program into smaller pieces; abstraction lets you think about what each piece does without examining its implementation. You can write a piece once and reuse it with different inputs. section 21.0
Figure 20.2. “Find in warehouse” shown with and without a black box over the task. Seeing the details of how the item is found and retrieved in the warehouse doesn’t add any more understanding of the task itself.
Compare finding an item in a warehouse with and without its details covered. The input and result still tell you what the task accomplishes. section 20.1
A function can put this idea into code. Parameters let callers supply different inputs; a docstring states the inputs, the function’s job, and what it returns. A caller can read that description instead of reading every implementation step. section 21.3
def take_attendance(classroom, who_is_here):
"""
classroom, tuple of strings
who_is_here, tuple of strings
Prints the names of all kids in class who are also in who_is_here
Returns a string, "finished taking attendance"
"""
The attendance function’s docstring identifies two inputs, says that it prints matching students’ names, and states its return value. What would you need to know to call it? Which implementation details could stay hidden? section 21.3
A stack without the bookkeeping
A stack of pancakes can be represented with a list. Without a stack object, you must remember to add and remove items at the correct end of that list. A Stack class instead offers operations for adding and removing items, so code using it can ask for the behavior without repeating the list-handling details. section 32.1
Classes can hide details in larger programs, too. In a card game, class definitions describe the objects and their operations; gameplay code creates objects and calls their methods. An abstraction is useful when it makes that work clearer—not merely because it creates another class. If an Hour class would only wrap an integer without adding value, the integer may be enough. section 34.7 section 33.4
