{"id":402,"date":"2026-07-02T12:19:35","date_gmt":"2026-07-02T12:19:35","guid":{"rendered":"http:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/?p=402"},"modified":"2026-07-02T12:23:22","modified_gmt":"2026-07-02T12:23:22","slug":"single-responsibility-principle","status":"publish","type":"post","link":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/2026\/07\/02\/single-responsibility-principle\/","title":{"rendered":"Single Responsibility Principle"},"content":{"rendered":"\n

One Class \u2014 One Reason to Change<\/h4>\n\n\n\n

The Single Responsibility Principle (SRP)<\/strong> states that a class should have only one reason to change.<\/p>\n\n\n\n

\n

\u201cA class should have only one reason to change.\u201d \u2014 Robert C. Martin<\/p>\n<\/blockquote>\n\n\n\n

Simply put:<\/p>\n\n\n\n

One class = one responsibility.<\/strong><\/p>\n\n\n\n

This means that a class may perform multiple operations, but they should all belong to a single, clearly defined area of responsibility.<\/p>\n\n\n\n

Real-Life Example: How to Understand It?<\/h4>\n\n\n\n

Imagine an employee in a company who is responsible for:<\/p>\n\n\n\n

    \n
  • answering phone calls,<\/li>\n\n\n\n
  • handling accounting,<\/li>\n\n\n\n
  • repairing computers,<\/li>\n\n\n\n
  • recruiting new employees.<\/li>\n<\/ul>\n\n\n\n

    At first glance, this may seem efficient \u2014 one person handles everything. However, problems arise whenever changes occur in any of these areas.<\/p>\n\n\n\n

    Change in Accounting<\/h3>\n\n\n\n

    The company introduces new tax regulations or changes the invoicing process. The employee must learn new procedures and adapt the way they perform accounting tasks.<\/p>\n\n\n\n

    Change in Recruitment<\/h3>\n\n\n\n

    The HR department decides to add a new stage to the interview process or modify candidate application forms. Once again, the same employee must adjust their work, even though this change has nothing to do with accounting.<\/p>\n\n\n\n

    As a result, a single person becomes dependent on changes occurring in many completely different areas of the business. Every new procedure, regulation, or requirement forces them to modify the way they work.<\/p>\n\n\n\n

    The exact same problem occurs in software development.<\/p>\n\n\n\n

    If a single class:<\/p>\n\n\n\n

      \n
    • saves data to a database,<\/li>\n\n\n\n
    • sends emails,<\/li>\n\n\n\n
    • generates reports,<\/li>\n\n\n\n
    • prints documents,<\/li>\n<\/ul>\n\n\n\n

      then every change in any of these areas requires modifications to the same class.<\/p>\n\n\n\n

      As a consequence:<\/p>\n\n\n\n

        \n
      • the code becomes larger and more complex,<\/li>\n\n\n\n
      • the risk of introducing bugs increases,<\/li>\n\n\n\n
      • testing becomes more difficult,<\/li>\n\n\n\n
      • understanding the class’s responsibility becomes harder.<\/li>\n<\/ul>\n\n\n\n

        According to SRP, it would be better to hire four specialists:<\/p>\n\n\n\n

          \n
        • an accountant,<\/li>\n\n\n\n
        • a recruiter,<\/li>\n\n\n\n
        • an IT specialist,<\/li>\n\n\n\n
        • a customer service representative.<\/li>\n<\/ul>\n\n\n\n

          In software development, the equivalent of these specialists is a set of separate classes, each responsible for a specific area. This way, a change in accounting does not affect the IT specialist’s work, and changes in recruitment do not require modifications to customer service processes.<\/p>\n\n\n\n

          This is exactly what \u201cone reason to change\u201d<\/strong> means.<\/p>\n\n\n\n

          Example \u2014 SRP Violation<\/h4>\n\n\n\n

          Suppose we are building an e-commerce system.<\/p>\n\n\n\n

          The OrderService<\/code> class below violates SRP because it has three reasons to change<\/strong>:<\/p>\n\n\n\n

            \n
          • saving orders,<\/li>\n\n\n\n
          • sending emails,<\/li>\n\n\n\n
          • printing invoices.<\/li>\n<\/ul>\n\n\n
            <\/pre>\n
            class OrderService {<\/div>\n
            \u00a0<\/pre>\n
            \u00a0\u00a0\u00a0 public void saveOrder(Order order) {<\/div>\n
            \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ save to database<\/div>\n
            \u00a0\u00a0\u00a0 }<\/div>\n
            \u00a0<\/pre>\n
            \u00a0\u00a0\u00a0 public void sendConfirmationEmail(Order order) {<\/div>\n
            \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ send email to customer<\/div>\n
            \u00a0\u00a0\u00a0 }<\/div>\n
            \u00a0<\/pre>\n
            \u00a0\u00a0\u00a0 public void printInvoice(Order order) {<\/div>\n
            \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ print invoice<\/div>\n
            \u00a0\u00a0\u00a0 }<\/div>\n
            }<\/div>\n\n\n
            The class has three different reasons to change:<\/p>\n\n\n\n
            If the data storage mechanism changes (for example, migrating from MySQL to PostgreSQL):<\/p>\n\n\n
            <\/pre>\n
            public void saveOrder(Order order) {<\/div>\n
            \u00a0\u00a0\u00a0 \/\/ save to database<\/div>\n
            }<\/div>\n\n\n
            If the email delivery method changes:<\/p>\n\n\n
            <\/pre>\n
            public void sendConfirmationEmail(Order order) {<\/div>\n
            \u00a0\u00a0\u00a0 \/\/ send email to customer<\/div>\n
            }<\/div>\n\n\n
            If the invoice format changes (for example, a new field must be added):<\/p>\n\n\n
            <\/pre>\n
            public void printInvoice(Order order) {<\/div>\n
            \u00a0\u00a0\u00a0 \/\/ print invoice<\/div>\n
            }<\/div>\n\n\n
            Where Does the Change Come From? The Actor Concept<\/h4>\n\n\n\n
            It is worth asking: who causes changes to each method in the OrderService<\/code> class?<\/strong><\/p>\n\n\n\n
              \n
            • Changes in saveOrder()<\/code> may be required by the infrastructure team, for example, due to a database migration from MySQL to PostgreSQL.<\/li>\n\n\n\n
            • Changes in sendConfirmationEmail()<\/code> may be required by the marketing department, for example, due to a new email template.<\/li>\n\n\n\n
            • Changes in printInvoice()<\/code> may be required by the accounting department, for example, because a new field must appear on invoices.<\/li>\n<\/ul>\n\n\n\n
              In Robert C. Martin’s terminology, each of these entities is an actor<\/strong> \u2014 a specific person or team responsible for a business area and the only one who should have a reason to request changes in a class.<\/p>\n\n\n\n
              \n
              \u201cA module should be responsible to one, and only one, actor.\u201d \u2014 Robert C. Martin, Clean Architecture<\/em><\/p>\n<\/blockquote>\n\n\n\n
              If three different people from three different departments can independently request modifications to the same class, that is a strong indication that the class violates SRP.<\/p>\n\n\n\n
              This is why the definition talks about a reason to change<\/strong>, not the number of methods.<\/p>\n\n\n\n
              A class may contain many methods and still comply with SRP,<\/p>\n\n\n\n
              provided that all changes are driven by decisions from the same actor.<\/strong><\/p>\n\n\n\n
              Example \u2014 SRP Compliant Design<\/h4>\n\n\n\n
              We separate responsibilities into dedicated classes:<\/p>\n\n\n
              <\/pre>\n
              class OrderRepository {<\/div>\n
              \u00a0<\/pre>\n
              \u00a0\u00a0\u00a0 public void save(Order order) {<\/div>\n
              \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ save to database<\/div>\n
              \u00a0\u00a0\u00a0 }<\/div>\n
              }<\/div>\n
              \u00a0<\/pre>\n
              class EmailService {<\/div>\n
              \u00a0<\/pre>\n
              \u00a0\u00a0\u00a0 public void sendConfirmation(Order order) {<\/div>\n
              \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ send email to customer<\/div>\n
              \u00a0\u00a0\u00a0 }<\/div>\n
              }<\/div>\n
              \u00a0<\/pre>\n
              class InvoicePrinter {<\/div>\n
              \u00a0<\/pre>\n
              \u00a0\u00a0\u00a0 public void print(Order order) {<\/div>\n
              \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \/\/ print invoice<\/div>\n
              \u00a0\u00a0\u00a0 }<\/div>\n
              }<\/div>\n\n\n
              What Do We Gain?<\/h4>\n\n\n\n
              Each class is responsible for a single area:<\/p>\n\n\n\n
                \n
              • OrderRepository<\/code> is responsible for data persistence.<\/li>\n\n\n\n
              • EmailService<\/code> is responsible for sending emails.<\/li>\n\n\n\n
              • InvoicePrinter<\/code> is responsible for generating and printing invoices.<\/li>\n<\/ul>\n\n\n\n
                If the email delivery mechanism changes, we modify only the EmailService<\/code> class.<\/p>\n\n\n\n
                If the invoice format changes, we modify only the InvoicePrinter<\/code> class.<\/p>\n\n\n\n
                Why Is SRP Important?<\/h4>\n\n\n\n
                Easier to Understand<\/strong><\/p>\n\n\n\n
                Instead of one class containing 1,000 lines of code and performing 20 different tasks, we create classes whose names clearly indicate their responsibilities.<\/p>\n\n\n\n
                Easier Maintenance<\/strong><\/p>\n\n\n\n
                Changes made in one area do not trigger a chain reaction of modifications throughout the system.<\/p>\n\n\n\n
                Easier Testing<\/strong><\/p>\n\n\n\n
                Testing a class with a single responsibility is much easier than testing a class that performs many unrelated functions.<\/p>\n\n\n\n
                Lower Risk of Bugs<\/strong><\/p>\n\n\n\n
                When modifying code responsible for sending emails, we do not risk accidentally breaking invoice-related functionality.<\/p>\n\n\n\n
                When Should You Apply SRP?<\/h4>\n\n\n\n
                Apply SRP when:<\/p>\n\n\n\n
                  \n
                • a class has more than one reason to change,<\/li>\n\n\n\n
                • modifying one feature requires changes in unrelated parts of the class,<\/li>\n\n\n\n
                • testing a class is difficult because it does too much,<\/li>\n\n\n\n
                • a class contains many unrelated methods,<\/li>\n\n\n\n
                • it is difficult to describe the class’s responsibility in a single sentence.<\/li>\n<\/ul>\n\n\n\n
                  A good class does one thing well.<\/strong><\/p>\n\n\n\n
                  As a result, the code becomes simpler, more readable, easier to test, and easier to maintain and extend.<\/p>\n","protected":false},"excerpt":{"rendered":"
                  One Class \u2014 One Reason to Change The Single Responsibility Principle (SRP) states that a class should have only one reason to change. \u201cA class should have only one reason to change.\u201d \u2014 Robert C. Martin Simply put: One class = one responsibility. This means that a class may perform multiple operations, but they should […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"saved_in_kubio":false,"footnotes":""},"categories":[12],"tags":[],"class_list":["post-402","post","type-post","status-publish","format-standard","hentry","category-solid"],"_links":{"self":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/402","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/comments?post=402"}],"version-history":[{"count":3,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/402\/revisions"}],"predecessor-version":[{"id":406,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/402\/revisions\/406"}],"wp:attachment":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/media?parent=402"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/categories?post=402"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/tags?post=402"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}