God Class antipattern — low cohesion and high coupling
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
A God Class is a class that becomes the application's decision center for many unrelated concerns. For example, one ApplicationManager might validate orders, write SQL, charge cards, send email, and format reports. Those responsibilities change for different reasons, so cohesion is low. As controllers and jobs call its broad API, coupling and change blast radius grow.
I would not say one mistake necessarily breaks the whole system or that every class must depend on it. The practical signals are unrelated imports, many reasons to change, shared mutable state, and changes that repeatedly affect distant workflows. I would add characterization tests, identify cohesive capabilities such as payment and notification, and extract them gradually while keeping real transactional invariants together.
God Class antipattern — low cohesion and high coupling
Direct Answer
A God Class is an oversized design center that owns many unrelated decisions and is consulted by many parts of the system. It has low cohesion because its responsibilities change for different reasons, and it often increases coupling because clients depend on its state or broad API. Not every class must depend on it, but its change blast radius is usually large.
Code Example
// GOD CLASS - handles everything
@Service
class ApplicationService {
public User createUser(String name, String email) { /* user logic */ }
public void sendEmail(String to, String msg) { /* email logic */ }
public Order processOrder(Long userId, List<Item> items) { /* order logic */ }
public double calculateTax(double amount, String state) { /* tax logic */ }
public String generateInvoice(Order order) { /* PDF logic */ }
public void logActivity(String action) { /* logging logic */ }
// 2000 more lines of unrelated methods...
}
// REFACTORED - split into focused services
@Service
class UserService {
private final UserRepository userRepository;
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
public User createUser(String name, String email) {
var user = new User(name, email);
return userRepository.save(user);
}
}
@Service
class OrderService {
private final OrderRepository orderRepository;
private final TaxCalculator taxCalculator; // low coupling via interface
public OrderService(OrderRepository orderRepository, TaxCalculator taxCalculator) {
this.orderRepository = orderRepository;
this.taxCalculator = taxCalculator;
}
public Order processOrder(Long userId, List<Item> items) {
double subtotal = 0; for (Item it : items) subtotal += it.getPrice();
double tax = taxCalculator.calculate(subtotal);
var order = new Order(userId, items, subtotal + tax);
return orderRepository.save(order);
}
}
Common Mistakes & Pitfalls
- Defining it only by size: a large parser may be cohesive, while a smaller manager can mix unrelated work.
- Saying it automatically violates every SOLID principle: describe the concrete responsibility and dependency problems instead.
- Creating an interface for every extracted class: use contracts where they clarify or protect a boundary.
- Splitting everything at once: large rewrites can lose behavior and transaction rules.
- Creating several smaller grab bags: each new class still needs a clear purpose and ownership.
Check your understanding
Answer these without looking back at the article.
- How do you refactor a God Class?
- What causes God Classes to appear in codebases?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.