High Cohesion vs Low Cohesion
High cohesion vs low cohesion explained — single responsibility, the god class anti-pattern, and a Java refactor example for interview prep.
Expected Interview Answer
High cohesion means a class or module has a single, well-defined responsibility with all of its methods and fields working together toward that one purpose, while low cohesion means a class bundles several unrelated responsibilities, so its members serve different, disconnected goals.
A highly cohesive class is easy to name accurately, easy to test, and easy to reason about because every method it exposes relates directly to its stated purpose — a Parser class only parses. A low-cohesion class, sometimes called a “god class,” tends to accumulate unrelated behavior over time — a UserManager that also formats emails, calculates tax, and writes log files — because it is the path of least resistance to add “just one more method” to an existing class rather than creating a new one. Cohesion and coupling are closely linked: low-cohesion classes tend to force other classes to depend on more of their surface area than necessary, increasing coupling elsewhere in the system. The single responsibility principle is essentially a rule for keeping cohesion high.
- Classes are easier to name accurately and understand at a glance
- Changes to one responsibility don’t risk breaking unrelated behavior
- Highly cohesive classes are simpler to unit test in isolation
- Reduces the chance of accidental coupling between unrelated concerns
AI Mentor Explanation
A specialist opening batter trains purely for the demands of facing the new ball — footwork against swing, leaving deliveries outside off, building an innings — every drill in their program serves that one purpose. A player instead expected to open the batting, keep wicket, captain the side, and manage sponsorship deals has scattered, unrelated responsibilities pulling in different directions. The specialist is highly cohesive; the overloaded all-in-one role is low cohesion, and it shows in performance under pressure.
Step-by-Step Explanation
Step 1
List a class’s current responsibilities
Write down every distinct thing the class’s methods actually do.
Step 2
Check if they serve one purpose
Ask whether all responsibilities support a single, nameable role.
Step 3
Spot low cohesion
Unrelated responsibilities (e.g. formatting, persistence, business logic mixed together) signal low cohesion.
Step 4
Refactor toward single responsibility
Extract unrelated behavior into new, focused classes until each class has one clear reason to change.
What Interviewer Expects
- Clear, contrasting definitions of high vs low cohesion
- Connection to the single responsibility principle
- Recognition of the “god class” anti-pattern as the extreme of low cohesion
- Understanding of the link between low cohesion and increased coupling elsewhere
Common Mistakes
- Confusing cohesion with coupling (they measure different things, though they interact)
- Describing cohesion only vaguely without naming concrete symptoms
- Failing to mention the single responsibility principle as the guiding rule
- Assuming a large class is automatically low cohesion (size alone isn’t the measure — mixed purpose is)
Best Answer (HR Friendly)
“High cohesion means a class does one job and all of its methods work together toward that job, which makes the code easy to understand, test, and change safely. Low cohesion means a class has grabbed a bunch of unrelated responsibilities over time, so changing one part risks breaking something unrelated, and it becomes hard to even give the class an accurate name. The fix is to split unrelated responsibilities into their own focused classes, following the single responsibility principle.”
Code Example
// Low cohesion: unrelated responsibilities crammed into one class
class UserManager {
void createUser(String name) { /* persistence logic */ }
void sendWelcomeEmail(String email) { /* email formatting + sending */ }
double calculateUserDiscount(String tier) { /* pricing logic */ }
}
// High cohesion: each class has a single, focused purpose
class UserRepository {
void createUser(String name) { /* persistence logic only */ }
}
class EmailService {
void sendWelcomeEmail(String email) { /* email logic only */ }
}
class DiscountCalculator {
double calculateUserDiscount(String tier) { /* pricing logic only */ }
}Follow-up Questions
- How does the single responsibility principle relate to cohesion?
- What is a “god class” and why is it a sign of low cohesion?
- How does low cohesion tend to increase coupling elsewhere in a system?
- Can you give a real refactor where you split a low-cohesion class?
MCQ Practice
1. High cohesion in a class means?
High cohesion means every method and field in the class serves the same single, focused responsibility.
2. Which is a classic symptom of low cohesion?
A god class bundling unrelated responsibilities is the textbook example of low cohesion.
3. Which principle is most directly about keeping cohesion high?
The single responsibility principle states a class should have one reason to change, which is exactly the definition of high cohesion.
Flash Cards
High cohesion, one line? — A class has one well-defined purpose and every member serves it.
Low cohesion, one line? — A class bundles unrelated responsibilities that don’t share a common purpose.
Extreme example of low cohesion? — A "god class" doing persistence, emailing, pricing, and logging all at once.
Guiding principle? — Single responsibility principle — a class should have one reason to change.