Cohesion — what it is and why high cohesion is desirable
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Cohesion measures how well the responsibilities inside a class or module belong together. For example, a PasswordHasher that creates and verifies password hashes has a clear purpose. If it also sends emails and formats invoices, those new responsibilities change for unrelated reasons and cohesion drops.
I use cohesion as a design question rather than a size limit. A 300-line parser can still be cohesive if every part supports the same grammar and invariant. A short utility class can be incoherent if it mixes dates, files, and network calls. High cohesion usually makes a module easier to name, understand, and test, but the right boundary follows the business capability, not a rule that each service handles exactly one entity.
Cohesion — what it is and why high cohesion is desirable
Direct Answer
Cohesion describes how strongly the data and behavior inside a module contribute to one clear purpose. High cohesion means the parts change for related reasons and form a useful boundary. It is not measured by line count, one entity name, or a rule that every class must have exactly one tiny task.
Code Example
// LOW COHESION - UserService does everything
@Service
class UserServiceLowCohesion {
public void createUser(User user) { /* save user */ }
public void sendWelcomeEmail(String email) { /* send email */ }
public String generateInvoicePdf(Order order) { /* PDF logic */ }
public double calculateShippingCost(Address addr) { /* shipping */ }
public void logActivity(String action) { /* logging */ }
// unrelated responsibilities mixed together
}
// HIGH COHESION - each service has one focused purpose
@Service
class UserService {
private final UserRepository repository;
public UserService(UserRepository repository) {
this.repository = repository;
}
public User createUser(User user) {
validateUser(user); // cohesive: validates user data
return repository.save(user); // cohesive: persists user
}
public Optional<User> findById(Long id) {
return repository.findById(id); // cohesive: retrieves user
}
private void validateUser(User user) { /* validation logic */ }
// all methods relate to user entity operations
}
@Service
class NotificationService {
public void sendWelcomeEmail(String email) { /* focused on notifications */ }
}
Common Mistakes & Pitfalls
- Using class length as the metric: size is a signal, not the definition.
- Making one service per database entity: business capabilities often cross entities.
- Splitting every method into a new class: excessive fragmentation can scatter one invariant.
- Keeping unrelated work in a generic utility class: convenience is not cohesion.
- Assuming high cohesion guarantees easy tests: external dependencies and API design still matter.
Check your understanding
Answer these without looking back at the article.
- How is cohesion related to the Single Responsibility Principle?
- What is a God Class and how does it violate cohesion?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.