How do you determine that a class or module violates SRP?

An SRP violation is determined by analyzing how many different reasons could lead to a change in the same class or module. The main signs are as follows:

#1. The class performs logically different tasks

If operations belonging to different domains are combined inside one class, for example business logic, network access, and logging, that is a sign it has several responsibilities.

#2. Changes in different areas of the system affect the same class

If the class has to be changed when:

• business rules change,
• reporting requirements change,
• the input/output format changes,
• then it has several "reasons to change".

#3. Methods are not united by a single concept

When the class's methods are not unified by one goal. For example, one class has both calculatePrice() and saveToDatabase(). These are different areas of responsibility: calculation and storage.

#4. The class starts to grow, conditionals appear

Common signs:

• many if/else branches for different behavior variants,
• a large number of fields for "different tasks",
• the need to "think hard" about what this class even does. This means the class is trying to solve more than one problem.

#5. It is hard to write isolated tests

If testing the class requires mocking many unrelated dependencies (database, mail, logger), it is responsible for too much.

#6. The class name becomes too broad

When the name is something like Manager, Processor, Helper, Utils, a "service for every occasion" - this is almost always an SRP violation, because the class does not describe one role.

These signs make it possible to determine precisely that one component has taken on more than one responsibility.