Module 1 — Challenge Problems¶

Open problems, and there is more than one defensible answer to each. The reasoning is assessed as much as the result.

Challenge 1 — redesign the library as types, on paper [L5 Design]¶

The problem. Take the scenario from Lab 1 — items, members, lending — and design it as a set of types. No code. This is the bridge into Module 2, and it is deliberately paper-only: designing a type before you can write one keeps your attention on responsibilities instead of syntax.

For each type you propose, write:

its responsibility, in one sentence, with no "and";
the data it needs;
the operations it offers — named as the system speaks, not as the storage works (lend(), not setOnLoan()).

What a good answer contains. Types each of which has a single responsibility; at least one type you initially missed and had to add when a responsibility had nowhere to live; and a sentence that would fail for a Library class that tries to do everything.

The trap. A type called Library that holds the items, holds the members, computes fines, prints reports, and handles the menu. Every responsibility fits in it because it has no responsibility.

Challenge 2 — find every rule, and where it lives [L4 Analyze]¶

The problem. Rules are enforced by accident in procedural code. Take your Lab 1 program (or any 100–200 line program you have written) and find every implicit rule — "the count is never negative", "these arrays stay in step", "an identifier is unique".

For each rule, decide: is it enforced in one place, in several, or in none — that is, does it hold only because nobody has broken it yet?

What a good answer contains. At least five rules; for each, the specific lines that enforce it; and for each rule enforced in several places, a note on which copy you would keep if you could only keep one.

Why this matters. This list is the specification for the next fifteen labs. Every rule enforced in "none" is a bug waiting; every rule enforced in "several" is a divergence waiting.

Challenge 3 — your own system, and a named exclusion [L5 Design]¶

The problem. Choose a system you know well — course registration, a food ordering app, a gym's booking desk. List its candidate types and one operation each is responsible for. Then name one thing you deliberately did not make a type, and say why.

What a good answer contains. A negative decision you can defend: something that looks like an object but is better as a value, a function, or nothing at all. Naming what does not deserve a type is the skill Module 15 formalises.

What would make it weak. "I could not think of a reason not to" — that is a missing decision, not an easy one.

Evaluating your own answer¶

Write these three lines before reading any suggested approach. They are the evidence that you made a decision rather than produced a diagram.

My design, in one line:
The decision I am least sure about, and why:
What I would do differently if I knew the system would grow for two more years:

Then check each of your types against the two tests in Concepts §7: does the responsibility fit in one sentence without "and", and can you name one thing you left out?

A design where every noun became a class has not been designed. It has been transcribed.

Next: Self-assessment — questions with explained answers, and what full credit looks like.