A dependency exists when one class refers to another class or relies on its accessible behavior. Minimal dependencies make changes less likely to cascade across the design. section 4.2.2 section 1.4.1
Recognize dependencies by how one class reaches another:
- Treat a member variable that refers to another class as a persistent dependency; for example, Catalogue stores Book pointers in booklist. section 4.4.1
- Treat a parameter or local reference as a transient dependency; Catalogue depends on Attributes only while add() or find() runs. section 4.4.1
- Use arrows to show who depends on whom, and labels or multiplicity to show the member, quantity, or relationship detail. section 4.4.1
A change leak in Car and Driver
A Driver that directly calls Car operations such as step_on_brake(), insert_key(), turn_key(), and step_on_accelerator() must change when the car replaces its key and ignition with press_start_button(). The implementation change has leaked into Driver. Encapsulation and reduced dependencies prevent this kind of cascade. section 1.4.1
Reduce harmful dependencies through loose coupling and the Principle of Least Knowledge. Expose only what other classes need, hide implementation details, and let classes interact through narrow interfaces. Catalogue depends on Attributes through pointers and references without knowing how Attributes stores book attributes; Attributes does not depend on Catalogue. section 4.2.2 section 5.0
Figure 4.7 Class Catalogue has a transient dependency relationship on class Attributes, as shown by the dashed dependency arrow. The add() member function of class Catalogue receives a pointer to an Attributes object and the find() member function is passed a reference to an Attributes object. The dependency exists only during calls to these functions.
Inspect a UML example of a transient dependency between Catalogue and Attributes, including the function calls that create it. section 4.4.1
