Single Responsibility Principle

A class should have just one reason to change, meaning it should be responsible for a single part of the system's functionality. Keeping concerns separated reduces complexity, makes classes easier to understand, and prevents unintended side effects when one responsibility changes.

Examples:

• An Employee class that both manages employee data and prints timesheet reports has two reasons to change. Moving the report-printing logic into a dedicated TimesheetReport class ensures that a change to report format never risks breaking employee-data handling.

Synonyms: srp