Decomposing a Problem into Subprograms
Splitting a task into parts small enough to write and check one at a time, then wiring the parts together into the whole program.
What a learner can do afterwards
- Break a described program into three or four named jobs before writing any code
- Explain how to test a function on its own with chosen inputs and expected results
- State what each part takes in and what it gives back
1 · Read
You have passed arguments into functions and returned results. Decomposition uses those skills to split a larger program into named jobs. Plan the jobs before writing their code. Give each function a clear responsibility. If one function collects input, checks an answer and displays a message, you can separate those jobs to test answer checking without keyboard input or screen output.
For one round of rock, paper, scissors, plan four jobs: get the first pick, get the second pick, decide the result, then announce it. The first two jobs can call the same get_choice function. decide_winner compares the picks and applies the rules: rock beats scissors, scissors beats paper, and paper beats rock. Equal picks give a draw.
State each function's arguments, returned result and other actions. Here, get_choice() takes no arguments, reads one valid keyboard pick and returns it. decide_winner(first, second) takes both picks and returns "first player", "second player" or "draw". announce_result(result) takes that result and prints a message. With no explicit return, Python returns None. Printing is this function's useful action.
Test each function with chosen inputs and expected results. Before building keyboard input, test decide_winner directly. Rock against rock should return draw. Include tests for both players winning too. Compare each actual result with its expected result. Then test the joined program: correct parts can still receive the wrong values or be called in the wrong order.
For a new job, identify the information it needs and the result its caller needs next. In a classroom grid simulation, a robot's decision function can take a square's description and return move or wait. Another function collects the description; another carries out the chosen action. Some functions take no arguments, and some perform an action rather than return useful data.
Plan named jobs with clear responsibilities. State arguments, results and actions. Compare each part's results with expectations, then test their connections.
Lesson, questions, diagrams and flashcards about planning and testing subprograms independently written for this dataset.
Library-lookup and quiz-program readings and accompanying flashcards independently written for this dataset.
More to read
Planning a library lookup
A library lookup program lets a reader enter a title and find matching books. Before writing its code, describe the jobs and the information each job needs.
One function can collect the title. A search function can take that title and a catalogue as arguments, then return matching records. A display function can take those records and present them to the reader. The caller connects the jobs by passing values to the functions that need them.
You can test the search before building keyboard input. Supply a chosen title and a small test catalogue directly. Decide which records should match, then compare the returned records with that expectation. Include a title with no matches.
Describe arguments separately from other input. The title-collection function may take no arguments while still reading from a person. The display function may produce output without returning useful data.
After testing the parts, test the full lookup. A search function can work correctly on its own while the caller passes the wrong title or sends unrelated records to the display function.
Checking a quiz in parts
For a quiz, separate collecting a response, checking it and showing the result. The checking function needs the response and the expected answer. It does not need to ask the player a question during each test.
Suppose check_answer(given, expected) returns True when its two arguments match and False otherwise. A test can call check_answer("green", "green") and expect True. Another can call check_answer("orange", "green") and expect False. Both tests run without keyboard input or screen output.
The caller connects the jobs: collect a response, pass it and the expected answer into checking, then pass the returned decision into display. Test these connections too. A caller that uses the previous response instead of the current response can display an incorrect result even when checking works correctly.
The number of functions depends on the task. Split responsibilities where that helps you write, reuse or check the program. Two jobs that do the same work on different values may call one shared function. You do not need a new function for every individual statement.
2 · Watch
En anglaisTake it off screen
Where it sits
8 questions wait behind this lesson, each with its answer explained. Every answer feeds the sky: stars light as they are learned, and dim when it is time to come back.