Class responsibilities and collaboration diagrams

≈ 45 min

Class responsibilities and collaboration diagrams

A class diagram names structures; a collaboration or sequence sketch shows messages over time. Use both to test an object-oriented design. Start with a user goal such as borrowing a book, then ask which object knows enough to perform each step. Give data and rules to the object that owns them rather than collecting every decision in a controller class.

Cohesion is high when a class’s fields and methods support one focused purpose. Coupling rises when one class knows too much about another class’s internal details. Good diagrams expose a small message such as loan.close(today) instead of a distant object changing returnedDate, fineAmount and status individually.

Worked reasoning. For a borrowing request, Member requests a Loan from LibraryService; LibraryService checks Book availability; Loan records the dates; Book changes availability through its own method. The diagram helps reveal a missing responsibility: only Book should decide whether it can be borrowed, because it owns that state.

Exam lens. When given a scenario, identify nouns, actions and invariants, then justify the ownership of the most important action. Do not assume every noun needs a class.

Which statement is the most defensible principle for Class responsibilities and collaboration diagrams?

A collaboration diagram should show which object owns each responsibility, not merely which objects exist.

Treat an implementation detail as more important than the stated rule.

Assume one successful run proves the system is correct in every case.

Avoid recording assumptions, limits or failure conditions.

Enter the key term for Class responsibilities and collaboration diagrams. What design quality means a class’s methods belong together around one purpose?

A UserInterface object updates every field of an Order directly. Which design move improves cohesion and protects invariants?

Move order-state changes into Order methods and let the interface request those methods instead of changing fields.

Use a larger class or broader permission without stating a rule.

Trust the first output and skip a boundary or failure check.

Hide the decision so affected people cannot inspect it.

Name the concise safeguard or principle that completes this lesson’s scenario: A UserInterface object updates every field of an Order directly. Which design move improves cohesion and protects invariants?