High cohesion keeps the parts of a component closely related to one responsibility. It makes code easier to understand because responsibility-specific logic stays together instead of scattering across the codebase. Aim for high cohesion within modules, layers, or classes while keeping coupling low between them. section 9.1.1
Separate unrelated responsibilities
An OrderTools class that calculates subtotals, applies discounts, and sends confirmation emails is a grab bag of unrelated actions. Moving pricing operations into PricingService and communication into NotificationService gives each class one clear responsibility and reduces the cognitive load of understanding either class. 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
}
}
Inspect the mixed responsibilities in OrderTools before separating its pricing and communication logic. 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
}
}
Compare the focused services: PricingService owns pricing behavior, while NotificationService owns customer notification. section 9.1.1
Cohesion is a design judgment rather than an isolated rule. Architecture reviews can look for low cohesion through large classes, misplaced responsibilities, or files that change frequently, but the resulting tradeoffs still require human judgment and system context. section 9.4.2
