Abstract Organization
SOLID Principles #1

Single Responsibility Principle

"A module should be responsible to one, and only one, actor."

play_circle Interactive Demo quiz Take Quiz

What does it actually mean?

The most common misunderstanding is thinking SRP means "a class should do only one thing."

The Real Definition: A class should have only one reason to change. In software architecture, a "reason to change" corresponds to a specific group of people—an Actor—who requires that change.

"Gather together the things that change for the same reasons. Separate those things that change for different reasons."

— Robert C. Martin (Uncle Bob)

link Source
Interactive Visualization

The Employee Paradox

Explore the classic "God Object" violation. Hover over the methods in the code to see which "Actor" owns them.

Employee.java (SRP Violation)
public class Employee {
public Money calculatePay() {
// Logic for salary, tax, bonuses...
return ...;
}
public String reportHours() {
// Logic for formatting timesheets...
return ...;
}
public void save() {
// Logic for SQL database persistence...
...
}
}

warning The Problem

This class has three reasons to change. If the CFO changes pay calculation rules, we edit this file. If the CTO changes the database schema, we edit this same file. This coupling risks accidental breakage (e.g., changing a shared utility function for pay calculation might break the hour report).

CFO

The CFO

Finance Dept

Responsible for calculatePay(). Requires changes to tax formulas & salary logic.

COO

The COO

Operations Dept

Responsible for reportHours(). Requires changes to report formats & compliance.

CTO

The CTO

IT / DBA

Responsible for save(). Requires changes to database schemas & persistence.

The Solution: Separation

Instead of one "God Class", we separate the concerns into distinct classes. Each class now has only one actor to answer to.

cancel

Monolithic Coupling

The current code mixes business rules, reporting logic, and database operations. Click "Refactor Code" to apply the Single Responsibility Principle.

data_object

EmployeeData

struct/class
- name
- address
- hourlyRate
Just a data structure. No logic. Passed between classes.
payments

PayCalculator

calculate(EmployeeData)
person Owned by CFO
summarize

HourReporter

report(EmployeeData)
person Owned by COO
storage

EmployeeRepository

save(EmployeeData)
person Owned by CTO

Test Your Understanding

Scenario 1: The Tax Law Change

The government changes the income tax calculation formula. In a properly refactored system, who is the actor requesting this change, and which class should be touched?

Scenario 2: Database Migration

We are moving from MySQL to PostgreSQL. Which module should be modified?