Design Questions¶
Ten open design problems. For each, give the classes, the relationships, the ownership rules and one trade-off you accepted. There is rarely a single correct answer; what is marked is whether your design is justified and whether it answers the question.
Mark yourself against the answers, which are model answers, not the only answers.
Answer in a shape. State the types and their one-line responsibilities; say which principle each relationship serves; and name the trade-off. A design with no stated trade-off has not been examined.
DQ1 — Bank account. A bank has accounts. An account has an owner, a balance and a movement history. Money may be deposited and withdrawn; a withdrawal larger than the balance must fail; every successful operation is recorded. Design the types, state the invariant, and name the one operation that enforces it.
DQ2 — Library lending. Items can be lent to members; each loan has a due date; a member may hold at most n items. Items and members exist independently of any loan. Design the types and the ownership relationships, and say where the "at most n" rule lives.
DQ3 — Shape rendering. A tool draws circles, rectangles and triangles, and must be able to add a new shape without editing any existing class. It also needs to compute the total area of a collection. Design the abstraction and the loop, and name the principle your design satisfies.
DQ4 — Payment processing. The checkout must accept card, wallet and bank-transfer payments; a new method arrives every few months. Each method has its own failure modes. Design the abstraction and the failure handling, and say how adding a method changes no existing class.
DQ5 — Notification hub. Events ("order placed", "payment failed") are consumed by an emailer, a logger and a dashboard; more consumers will be added; one must stop listening at run time. Design the hub, state the interface, and give the ownership and unsubscription rules.
DQ6 — Inventory lookup. A warehouse looks up items by barcode (fast), lists them in barcode order for reports, and counts how many are low on stock. Design the storage and justify each container with a complexity claim, and state the invariant that keeps the structures consistent.
DQ7 — Plugin registry. An application loads exporters that declare a file extension and can export a document. New exporters are added as separate units; a component that lies about its capabilities must be rejected at registration. Design the registry and the registration checks.
DQ8 — Persistence boundary. A workshop system must save and load its state to a file, and must be testable without touching the disk. Design where the file format lives and how a test substitutes an in-memory store, and state the dependency direction.
DQ9 — Refactoring a conditional. A shipping-cost function has grown an if for each
method and is edited every quarter. Refactor it, and say what a caller does to add a fifth
method.
DQ10 — Capstone architecture. An equipment-workshop system tracks equipment, members, loans and maintenance, persists to a file, and must be testable module by module. State the layers, the dependency direction, the interfaces that allow substitution, and one part you would build last and why.
Then: compare with the model answers, and score yourself with Marking Yourself.