A black box is a way to understand a task without first seeing every step inside it. Start with what goes in, what the task does, and what comes out. The hidden steps are its implementation: the way you write the code to complete the task. section 20.1 section 2.3
To sketch a black box before coding:
- Write down sample inputs and the outputs you expect. section 2.3
- Ask whether the task interacts with a user or behaves differently in special situations. section 2.3
- For a larger task, draw smaller boxes and document what each one expects and returns. section 20.1
Changing a TV channel
Pressing a remote button produces a signal. The TV receives that signal, and what you see or hear changes. You can describe both devices by their inputs, behavior, and outputs without knowing how to assemble either one. section 20.2
In a program, a small black box can become a code module: a piece of code for one task. Modules can pass outputs to one another to accomplish a larger goal. Keeping their details out of view helps you focus on how the pieces fit together; writing each task separately also makes it easier to test. section 20.2 section 20.4
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 the warehouse task with and without its hidden steps. The inputs and outputs stay the same, even when the retrieval details are out of view. section 20.1
Quick check: If a program finds an item in a warehouse, what must another part of the program provide, and what should it receive back? Answer that before deciding how the search works. section 20.1
