Association
Association means one object knows or communicates with another. The link says nothing by itself about who owns the other object or controls its lifetime.
What you’ll understand
- Association means one object knows or communicates with another. The link says nothing by itself about who owns the other object or controls its lifetime.
- Booking keeps a reference to Customer and reads the display name through that reference.
- Evaluate the tradeoff: Live references avoid stale duplicates but expose changes over time. A historical invoice may intentionally need a value snapshot instead; choose from the domain requirement.
Useful first: Classes and Objects
The idea and when to recognize it
Association means one object knows or communicates with another. The link says nothing by itself about who owns the other object or controls its lifetime.
- Requirement: A booking refers to a customer. The booking should observe the customer’s current display name without keeping a stale duplicate.
- Change to anticipate: Rename the customer after creating a booking and have the booking use the same customer identity.
- Design goal: Booking keeps a reference to Customer and reads the display name through that reference.
Start with the concrete problem
A booking refers to a customer. The booking should observe the customer’s current display name without keeping a stale duplicate.
Rename the customer after creating a booking and have the booking use the same customer identity.
| Direct implementation | Revised design |
|---|---|
| Copying a customer name when a live relationship was required loses later updates. | Booking keeps a reference to Customer and reads the display name through that reference. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Live references avoid stale duplicates but expose changes over time. A historical invoice may intentionally need a value snapshot instead; choose from the domain requirement. |
Responsibilities and contracts
Booking keeps a reference to Customer and reads the display name through that reference.
- Booking: Refers to one customer. Public operations: customer, label()
- Customer: Owns the current name. Public operations: rename(name)
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
A course can refer to an instructor who continues to exist after the course is archived.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
Live references avoid stale duplicates but expose changes over time. A historical invoice may intentionally need a value snapshot instead; choose from the domain requirement.
Common mistake: Copying a customer name when a live relationship was required loses later updates.
- Explain the choice: Booking keeps a reference to Customer and reads the display name through that reference.
- Challenge your choice: Live references avoid stale duplicates but expose changes over time. A historical invoice may intentionally need a value snapshot instead; choose from the domain requirement.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…