Contracts and Interfaces — Test Your Understanding

Answer each question by writing contracts in plain language. No code. Focus on precision and completeness.

Section A: Write the Contract

Question 1

Write the contract for a password reset operation. A user provides their email address and requests a password reset. Think through: what are all the inputs? What are all the outputs? What can go wrong? What side effects occur?

Use the template:

CONTRACT: ResetPassword
ACCEPTS: ...
RETURNS: ...
ERRORS: ...
SIDE EFFECTS: ...

Question 2

Write the contract for searching a product catalog. A user can search by keyword, filter by category, filter by price range, and choose how results are sorted. Define every input (required vs. optional, constraints), exactly what the output looks like, and what happens when no results match.

Question 3

Write the contract for transferring money between two bank accounts. This is a high-stakes operation. Be thorough: think about validation, insufficient funds, daily transfer limits, accounts that don't exist, accounts that are frozen, and what happens if the system fails mid-transfer.

Section B: Evaluate the Contract

Question 4

Here is a contract someone wrote:

CONTRACT: GetUser
ACCEPTS: user_id
RETURNS: user data
ERRORS: returns error if something goes wrong

List every problem with this contract. Then rewrite it properly.

Question 5

Here is a more detailed contract:

CONTRACT: SubmitReview
ACCEPTS:
  - product_id: text
  - user_id: text
  - rating: number (1-5)
  - review_text: text
RETURNS:
  - review_id: text
ERRORS:
  - invalid product → error
  - invalid user → error

This is better, but still incomplete. Identify at least five things that are missing or underspecified. Rewrite the contract to address them.

Question 6

You receive two different contract proposals for the same operation — sending a notification to a user:

Proposal A:

CONTRACT: SendNotification
ACCEPTS: user_id, message_text, channel (email/push/sms)
RETURNS: success/failure
ERRORS: user not found, invalid channel

Proposal B:

CONTRACT: SendNotification
ACCEPTS: user_id, message_text
RETURNS: notification_id, channel_used, status
ERRORS: user not found, user has no valid contact methods, message too long
SIDE EFFECTS: notification logged, delivery attempted via user's preferred channel

Compare these proposals. Which is better and why? What does Proposal B handle that Proposal A ignores? Is there anything Proposal A does better?

Section C: Contract Composition

Question 7

A food delivery app has the following user action: "Customer places an order from a restaurant."

Break this into a chain of individual contracts. Each contract should have full inputs, outputs, errors, and side effects. The chain should cover everything from the customer pressing "Place Order" to the restaurant receiving the order on their screen.

Define at least 4 contracts in the chain. For each one, show how the output of the previous step feeds into the input of the next.

Question 8

An event ticketing system needs to handle: "User purchases 3 tickets for a concert."

This involves checking seat availability, holding seats temporarily while the user pays, processing payment, and issuing the tickets. These steps must happen in order, and failure at any step has specific consequences.

Write the contract chain. Pay special attention to: what happens if seats are taken between checking availability and completing payment? What happens if payment fails after seats are held?

Question 9

A user wants to change their email address in a system. This seems simple but involves:

• Verifying the new email is valid and not already in use
• Sending a verification link to the new email
• The user clicking the link to confirm
• Updating the email in the system
• Notifying the old email address about the change

Write contracts for each step. Identify where time gaps exist between steps (e.g., the user might click the link 5 minutes later, or never). How do the contracts handle these gaps?

Section D: Critical Thinking

Question 10

"A good contract should cover every possible edge case."

Is this true? Is it realistic? Where do you draw the line between thoroughness and over-specification? Give an example of an edge case that MUST be in the contract and one that reasonably could be omitted.

Question 11

You write a contract that says:

RETURNS: list of orders, sorted by date descending, maximum 100 results

A colleague argues: "Don't put 'maximum 100' in the contract. That's an implementation detail — maybe we'll change it later."

Who is right? Make the case for each side. What is the cost of including it in the contract? What is the cost of leaving it out?

Question 12

A contract exists between Module A and Module B. Module A has been happily calling Module B for a year. Now Module B needs to add a new required input to the contract.

What problem does this create? How would you handle this change without breaking Module A? Describe at least two approaches and the tradeoffs of each.

Grading Rubric