中文（繁體）
中文（简体）
English
DSE ICT | Object-Oriented Design and Debugging Prep Guide (for tutors) | 3 classes, 12 methods, 18 tests
Students put the whole program inside one class and then hunt for bugs with print. This lesson does only two things: split responsibilities and write boundary tests first.
Objectives — Students will be able to: (1) name three classes for a small library system (Book, Member, Loan) with one responsibility each; (2) explain the split between attributes and methods and give each class four methods, twelve in total; (3) write six boundary cases out of eighteen tests (33.3%) and use tests, not print, to locate a fault.
01 Prerequisites (3-minute check)
If any of these fails, fix it before the lesson starts.
| Skill | Quick check | Pass mark |
|---|---|---|
| Variables and types | When do you use a list and when a dict | Ordered collection vs key-value mapping |
| Functions | What is the difference between a parameter and a return value | Input via parameter, output via return |
| Conditions and loops | What stops a for loop and what stops a while loop | Known count vs condition met |
02 Lesson flow (45 minutes)
| Time | Stage | Tutor does | Student does |
|---|---|---|---|
| 0-5 min | Assign responsibilities | Write one sentence per class | Three sentences, none overlapping |
| 5-15 min | Attributes first | List five attributes, then twelve methods | Each attribute maps to an operation |
| 15-25 min | Boundary cases | Show empty, duplicate and over-limit cases | Six boundary tests written |
| 25-40 min | Debug with tests | Plant one bug, locate it by test | 18 tests run in 27 minutes |
| 40-45 min | Exit check | One question each on responsibility, boundary and order | All three correct |
03 Teaching script (read it out)
Scene 1: Responsibility before methods: three classes, one sentence each
A library system needs only 3 classes: Book holds a single copy and its state (within 5 attributes), Member holds who borrowed what, and Loan holds the due date and the fine. Give each class 4 methods for 12 in total, which is exactly enough for one 45-minute demonstration.
The test for a misplaced method is simple: if a method needs both the book price and the member address, it is in the wrong class. A due date needs both the book and the member, so Loan exists to reference both rather than merging them.
Most students write one class called System that holds everything. Count with them: how many methods touch all three kinds of data? More than two means responsibilities have not been split.
The test for a misplaced method is simple: if a method needs both the book price and the member address, it is in the wrong class. A due date needs both the book and the member, so Loan exists to reference both rather than merging them.
Most students write one class called System that holds everything. Count with them: how many methods touch all three kinds of data? More than two means responsibilities have not been split.
Ask the student: should the fine calculation live in Book, Member or Loan, and why.
Scene 2: Attributes before behaviour: five attributes shape twelve methods
Write attributes first, then methods. Book has isbn, title, author and available; Member has id, name and borrowed; Loan has book, member and due date. Once the attributes are fixed, a method is simply an operation on them: read, change, validate.
This keeps the method count honest. Five attributes usually need four methods: one to create, one to read, one to change, one to validate. A class with twelve methods almost always holds attributes that belong to another class.
Encapsulation is worth teaching for a practical reason rather than a slogan: attributes are the only place state can be corrupted, so concentrating changes in one place fixes the scope of debugging.
This keeps the method count honest. Five attributes usually need four methods: one to create, one to read, one to change, one to validate. A class with twelve methods almost always holds attributes that belong to another class.
Encapsulation is worth teaching for a practical reason rather than a slogan: attributes are the only place state can be corrupted, so concentrating changes in one place fixes the scope of debugging.
Ask the student: who changes available, and what must be checked before the change.
Scene 3: Debug order: boundary tests before print
Of the 18 tests, keep 6 as boundary cases, which is 33.3%. The three kinds are fixed: borrowing a copy that is already out, borrowing beyond the limit, and returning after the due date. These cover most real faults and can be written without reading the whole program.
Allow 1.5 minutes per test, so 18 tests take 27 minutes; going beyond that means the tests are too fine-grained or the program has no testable interface.
The debugging order is fixed: run the tests, see which one is red, add one assertion inside that method, print only the input and the intermediate value, then delete the print once fixed. Prints left in a script lose marks because they change the output format.
Allow 1.5 minutes per test, so 18 tests take 27 minutes; going beyond that means the tests are too fine-grained or the program has no testable interface.
The debugging order is fixed: run the tests, see which one is red, add one assertion inside that method, print only the input and the intermediate value, then delete the print once fixed. Prints left in a script lose marks because they change the output format.
Ask the student: why borrowing an unavailable copy counts as a boundary case and not the normal path.
04 Question types and worked steps
| Type | Example | Steps | Answer |
|---|---|---|---|
| Write a class skeleton | Give Book its attributes and methods | List attributes, map one operation each, write signatures only | class Book: isbn, title, available; borrow(), return_book() |
| Trace object state | What is available after two borrows | Write the attribute value after each method call | False; the second call should raise |
| Find the bug | Why is the fine wrong | Write the failing test, reproduce, narrow, fix one place | The date check used < instead of <= |
| Write a test | Two cases for returning a late book | One normal case and one boundary case with expected results | Fine equals days late times daily rate |
Sanity check (teach this): Check three numbers: 3 classes, 12 methods, 18 tests (of which 6 boundary). If one class holds more than ten methods, ask for its single responsibility; an inability to state it proves the split is missing. 27 minutes is a ceiling, not a target: eighteen tests taking 45 minutes means the tests are too fine-grained.
05 Independent practice (3 questions)
| Question | Answer | What to watch |
|---|---|---|
| Write three attributes and two method signatures for Loan. | book, member, due; create() and fine(). | Enough attributes to compute the fine, one job per method |
| Write a test where a member borrows past the limit. | Expect a BorrowLimitError and an unchanged borrowed count. | Checks state stayed unchanged rather than only that an error appeared |
| Find the bug: if due < today: fine = 0 | The condition is inverted; a fine should apply when due < today. | Can reproduce it with one test instead of reading the code |
06 Common mistakes and what to say
| Mistake | Student writes | Say this |
|---|---|---|
| Everything in one class | class System with 15 methods | “One class, one job. Count the methods that touch all three kinds of data.” |
| Attributes and methods out of balance | Two attributes, nine methods | “Methods operate on attributes. With two attributes, what does the ninth method operate on?” |
| Only happy-path tests | Eighteen tests that all borrow successfully | “Write the boundary cases first; only boundaries find bugs.” |
| Debugging with print and leaving it in | Six prints left in the submitted script | “Delete it when fixed; prints change output format and lose marks.” |
07 Homework (paper, section and question numbers)
- DSE ICT practice paper (programming section) — Question 4: list the classes and methods for the system, at most four methods per class, and mark six boundary tests.
- Same paper, database section — Question 6: convert the entity relationships into class attributes and name the attribute that needs validation.
08 Exit check (last 5 minutes)
| Question | Answer | Decision |
|---|---|---|
| What does each of the three classes do | Book state, Member records, Loan terms | Cannot name Loan means reteach responsibilities |
| How many of the eighteen tests are boundary | Six, or 33.3% | Two or fewer means reteach boundaries |
| What is the first debugging step | Run the tests and find the red one | Answering “add a print” means reteach the order |
09 Tutor FAQ
Must we use object orientation?
No, but when several entities share state a class is clearer than parallel lists and far easier to test.
How fine should the tests be?
One success case and one boundary case per method is enough; eighteen tests already cover twelve methods.
Can comments replace tests in the exam?
No. Comments do not run, so they cannot reveal a fault.
Find a tutor — freeTutor Registration →
A TutorZone lesson-prep guide. Written by the TutorZone team; questions and lesson flow are original and are not taken from any school or publisher material.
