Coupling measures how strongly software components interact or depend on one another. Many interactions create tight coupling; fewer interactions create loose coupling, which limits the ripple effect of change. section 9.1.1
Treat coupling as a design concern from the beginning. Separating responsibilities helps keep coupling low between modules while keeping cohesion high within each module. section 9.1.1 section 9.5
Separate unrelated responsibilities
An OrderTools class that calculates prices and sends confirmation emails combines unrelated responsibilities. Splitting it into PricingService and NotificationService gives each class a focused purpose and makes future changes more localized. section 9.1.1
public class OrderTools {
public Money calculateSubtotal(Order order) {
// compute subtotal
}
public Money applyDiscount(Order order) {
// apply discount logic
}
public void sendConfirmationEmail(Order order) {
// notify customer
}
}
Shows a single class combining pricing and communication responsibilities, illustrating a design with weak cohesion and potentially broader change impact. section 9.1.1
public class PricingService {
public Money calculateSubtotal(Order order) {
// compute subtotal
}
public Money applyDiscount(Order order) {
// apply discount logic
}
}
public class NotificationService {
public void sendConfirmationEmail(Order order) {
// notify customer
}
}
Shows pricing and notification responsibilities separated into focused classes, supporting high cohesion and lower coupling. section 9.1.1
Use coupling as a practical change-management heuristic:
- Inspect how many components must change when a class, method name, or parameter changes. section 9.1.1
- Keep related logic together and unrelated responsibilities apart. section 9.1.1
- Balance low coupling with high cohesion rather than pursuing isolation without regard for design tradeoffs. section 9.5 section 9.4.2
