Multiple Methods and SRP Compliance in Java
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Yes, absolutely.
A class can have many methods and still follow SRP. The principle is about having one responsibility, not one method. Method count is irrelevant.
What matters is whether all those methods serve the same cohesive concern. A good example is a repository. A UserRepository might have save, findById, findByEmail, update, delete, exists, and count.
That's seven methods, but they all do the same thing: manage data access for User entities. The class has one reason to change — if the database schema changes or we switch databases, all those methods might need updating, but they change together because they're part of the same responsibility.
Contrast that with a class that has just three methods, but one validates input, another sends emails, and the third writes to a log file. That's three unrelated concerns, so even with fewer methods, it violates SRP. The key is cohesion.
All the methods in an SRP-compliant class should be working toward the same goal. One pitfall is thinking SRP means you need tiny classes with one method each. That would give you UserSaver, UserFinder, UserUpdater classes, which is absurdly granular and makes the codebase a nightmare to navigate.
Focus on one responsibility, not one method. If every method in your class relates to the same concern, you're good, no matter how many there are.
Multiple Methods and SRP Compliance in Java
Direct Answer
Yes — a class can have many methods and still follow SRP as long as all those methods serve the same single responsibility. A UserRepository with save, findById, delete, and update has four methods but one responsibility: data access for User. Method count is irrelevant; concern count is what matters.
Code Example
// COMPLIANT: 8 methods, 1 responsibility (data access)
@Repository
class OrderRepository {
private final JdbcTemplate jdbc;
public void save(Order order) {
jdbc.update("INSERT INTO orders...", order.id(), order.total());
}
public Optional<Order> findById(Long id) {
return jdbc.query("SELECT * FROM orders WHERE id=?",
rs -> rs.next() ? Optional.of(mapRow(rs)) : Optional.empty(), id);
}
public List<Order> findByCustomerId(Long customerId) {
return jdbc.query("SELECT * FROM orders WHERE customer_id=?",
this::mapRow, customerId);
}
public void update(Order order) {
jdbc.update("UPDATE orders SET total=? WHERE id=?", order.total(), order.id());
}
public void delete(Long id) {
jdbc.update("DELETE FROM orders WHERE id=?", id);
}
public boolean exists(Long id) {
return jdbc.queryForObject("SELECT COUNT(*) FROM orders WHERE id=?",
Integer.class, id) > 0;
}
public long count() {
return jdbc.queryForObject("SELECT COUNT(*) FROM orders", Long.class);
}
private Order mapRow(ResultSet rs) throws SQLException {
return new Order(rs.getLong("id"), rs.getBigDecimal("total"));
}
// Eight methods, all serving one responsibility: Order data access
}
Common Mistakes & Pitfalls
- Confusing method count with responsibility count: Freshers often think SRP means one method per class, leading to absurd over-granularity like UserSaver, UserFinder, UserDeleter classes instead of one cohesive UserRepository with all related methods.
- Accepting utility dump classes: Allowing classes like Utils, Helper, or Manager to grow to hundreds of methods serving unrelated purposes just because 'SRP allows multiple methods.' Those violate SRP because the methods don't share a single responsibility.
- Forcing artificial splits: Breaking a cohesive 15-method repository into five separate classes just to reduce method count, which increases complexity without any design benefit and makes the codebase harder to navigate.
Check your understanding
Answer these without looking back at the article.
- How do you measure cohesion in a class?
- What is a God Class and how does it relate to SRP?
- Is the Java String class a good example of SRP?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.