Wren unrolls a long sheet of paper across the greenhouse floor. At the top he writes one word: Beacon.
"Beacon is too big to think about all at once," he says. "Let's break it into pieces."
Comet grabs a marker. "Reading the sensors is one piece. Checking the plants is another."
"And sending the report back to mission control," Wren adds.
Nova hovers above the sheet, projecting faint boxes in the air. "I found a pattern," she says.
"Each big piece has smaller pieces inside it. Keep splitting until each box is one clear job."
Comet draws the first arrow. The module chart has begun.
You will decompose Beacon into modules: a chart of boxes, each with one job.
Complex programs are designed as systems of modules. Each module has a specific role, and they all work toward one purpose.
Dividing a program into separate subprograms like this is called modularity.
| Module | Its one job | Parameter (input) | Return value (output) |
|---|---|---|---|
| average | Finds the mean of a list | a list of numbers | one number |
| checkPlant | Decides if a plant needs water | one water level | needs water or all good |
| readWater | Reads the water sensors | (none) | a list of readings |
| buildReport | Puts results into one message | the averages and statuses | a report string |
Copy this table onto paper and add a row for each new module on your chart.
Procedural abstraction lets you use a procedure knowing only what it does, not how it does it.
Whoever writes buildReport can call average without reading a single line inside it.
Procedural abstraction lets the solution to a big problem be built from solutions to smaller subproblems.
| Lab finding | True or false? |
|---|---|
| Each box in a good module chart has one clear job. | ? |
| To call average, you must know every line inside it. | ? |
| Splitting a program into subprograms is called modularity. | ? |
| Modules in a system work toward one overall purpose. | ? |
Great lab work, developer. Tomorrow you will meet a shared library and a random number helper.