6a:T497,A powerful mental model for understanding responsibility is the **Axis of Change**. Every responsibility represents a direction from which change can originate. A well-designed class should only be affected by changes along a single axis. Visualize it this way: Imagine your class as a point in space. Each responsibility is an axis—a dimension along which force can be applied. If your class has one responsibility, force from one direction can move it. If it has two responsibilities, forces from two different directions can move it—and those forces might pull in different directions, tearing the class apart. **Practical application:** For any class, identify the forces that could cause it to change: 1. **Business Rules** — Changes in domain logic, policies, algorithms 2. **Persistence** — Changes in how data is stored or retrieved 3. **Presentation** — Changes in how information is displayed or formatted 4. **Integration** — Changes in external systems or APIs 5. **Reporting** — Changes in analytics, auditing, or compliance requirements If a single class responds to changes in multiple of these areas, it likely has multiple responsibilities.6b:T592,// BAD: Multiple axes of change class Order { // Axis 1: Business Rules (changes when pricing policies change) calculateTotal(): number { let total = 0; for (const item of this.items) { total += item.price * item.quantity; } // Apply discount rules if (total > 100) total *= 0.9; return total; } // Axis 2: Persistence (changes when database schema changes) saveToDatabase(): void { const sql = ` INSERT INTO orders (id, customer_id, total, created_at) VALUES (${this.id}, ${this.customerId}, ${this.calculateTotal()}, NOW()) `; database.execute(sql); } // Axis 3: Presentation (changes when UI requirements change) toHtmlReport(): string { return `

Order #${this.id}

Total: $${this.calculateTotal().toFixed(2)}

`; } // Axis 4: Integration (changes when shipping provider API changes) submitToShippingProvider(): void { const shippingRequest = { orderId: this.id, weight: this.calculateTotalWeight(), destination: this.shippingAddress, }; fetch('https://shipping-api.example.com/orders', { method: 'POST', body: JSON.stringify(shippingRequest), }); } }6c:T66d,# BAD: Multiple axes of change class Order: # Axis 1: Business Rules (changes when pricing policies change) def calculate_total(self) -> float: total = sum(item.price * item.quantity for item in self.items) # Apply discount rules if total > 100: total *= 0.9 return total # Axis 2: Persistence (changes when database schema changes) def save_to_database(self) -> None: sql = f""" INSERT INTO orders (id, customer_id, total, created_at) VALUES ({self.id}, {self.customer_id}, {self.calculate_total()}, NOW()) """ database.execute(sql) # Axis 3: Presentation (changes when UI requirements change) def to_html_report(self) -> str: return f"""

Order #{self.id}

Total: ${self.calculate_total(): .2f }

""" # Axis 4: Integration(changes when shipping provider API changes) def submit_to_shipping_provider(self) -> None: shipping_request = { "orderId": self.id, "weight": self.calculate_total_weight(), "destination": self.shipping_address, } requests.post( 'https://shipping-api.example.com/orders', json = shipping_request )6d:T61d,// BAD: Multiple axes of change public class Order { // Axis 1: Business Rules (changes when pricing policies change) public BigDecimal calculateTotal() { BigDecimal total = BigDecimal.ZERO; for (OrderItem item : items) { total = total.add(item.getPrice().multiply( BigDecimal.valueOf(item.getQuantity()) )); } // Apply discount rules if (total.compareTo(BigDecimal.valueOf(100)) > 0) { total = total.multiply(BigDecimal.valueOf(0.9)); } return total; } // Axis 2: Persistence (changes when database schema changes) public void saveToDatabase() { String sql = String.format( "INSERT INTO orders (id, customer_id, total, created_at) " + "VALUES (%s, %s, %s, NOW())", id, customerId, calculateTotal() ); database.execute(sql); } // Axis 3: Presentation (changes when UI requirements change) public String toHtmlReport() { return String.format( "

" + "

Order #%s

" + "

Total: $%.2f

" + "

", id, calculateTotal() ); } // Axis 4: Integration (changes when shipping provider API changes) public void submitToShippingProvider() { ShippingRequest request = new ShippingRequest( id, calculateTotalWeight(), shippingAddress ); httpClient.post( "https://shipping-api.example.com/orders", request ); } }6e:T426,**Misconception #1: "SRP means small classes"** This is perhaps the most prevalent misunderstanding. SRP is not about class size—it's about class focus. A 500-line class that encapsulates a complex algorithm for a single business purpose may have one responsibility. A 20-line class that performs validation for two different business domains has two responsibilities. **Misconception #2: "Technical layers are responsibilities"** Controllers, Services, and Repositories aren't responsibilities in the SRP sense. They're architectural layers. A `UserService` that handles both user authentication (security team's domain) and user profile display (product team's domain) has two responsibilities, despite being a single "service." **Misconception #3: "Private methods add responsibilities"** Private helper methods are implementation details. If they support the class's single public responsibility, they don't add separate responsibilities. Having 10 private methods that all support one public feature is perfectly fine—they all serve the same actor.6f:T437,**The answer depends on context:** **1. Team Size and Structure** In a small team where one or two developers handle all authentication-related changes, a single `AuthenticationService` class might be appropriate. In a large organization with separate security, compliance, and user experience teams all touching authentication, finer-grained separation is needed. **2. Rate of Change** Areas that change frequently benefit from finer granularity. If password policies change monthly while login mechanics are stable, separate `PasswordPolicyValidator` from `LoginService`. **3. Testing Requirements** Code that requires complex test fixtures might benefit from extraction. If testing one aspect of a class requires elaborate mocking of unrelated dependencies, that's a sign of mixed responsibilities. **4. Cognitive Load** Humans can hold roughly 7±2 items in working memory. If understanding a class requires tracking too many distinct concepts simultaneously, it may benefit from separation—regardless of whether those concepts are "technically" one responsibility.63:{"json":{"id":"seed_5a6a4808d5898c2e19be3e563265b1d5","slug":"defining-responsibility","category":"System Design LLD","topic":"Defining 'Responsibility'","title":"What Does 'Responsibility' Really Mean?","description":"Master the nuanced understanding of responsibility in software design. Learn to identify, evaluate, and scope responsibilities correctly—the critical skill that separates engineers who truly understand SRP from those who merely quote it.","difficulty":"INTERMEDIATE","estimatedMinutes":55,"pages":[{"id":"seed_5bd1c0b37c342e12654766b005c666da","title":"What Constitutes a Responsibility","order":0,"content":[{"id":"opening-hook","title":"The Most Misunderstood Principle","content":[{"data":{"content":"The Single Responsibility Principle sounds deceptively simple: *a class should have one reason to change*. Yet ask ten developers what SRP means, and you'll receive ten different—often contradictory—answers. Some will say \"one method per class.\" Others will argue for \"one function per class.\" Many will offer vague platitudes about \"doing one thing.\"\n\n**None of these capture what SRP actually means.**\n\nThe confusion stems from a fundamental misunderstanding of the word *responsibility*. Most developers interpret it as \"function\" or \"task\" or \"action\"—leading to codebases fragmented into thousands of tiny, nearly useless classes, each containing a single method. This isn't SRP compliance; it's SRP misapplication.\n\nUnderstanding what truly constitutes a responsibility is the difference between applying SRP effectively and creating a maintenance nightmare disguised as \"clean code.\""},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the precise definition of 'responsibility' as intended by the Single Responsibility Principle. You'll learn to distinguish genuine responsibilities from mere functions, and you'll develop the analytical skills to correctly scope classes in real-world systems.","variant":"info"},"type":"callout"}]},{"id":"etymology-responsibility","title":"The Etymology of Responsibility","content":[{"data":{"content":"Before we dive into technical definitions, let's examine the word itself. **Responsibility** derives from the Latin *respondere*—\"to respond\" or \"to answer for.\" When we say someone is \"responsible\" for something, we mean they are **answerable** for it.\n\nThis etymology reveals the true nature of responsibility in software design:\n\n> **A responsibility is something you must answer for—something that, when it changes, requires you to respond.**\n\nThis is precisely what Robert C. Martin (Uncle Bob) means when he says a class should have \"one reason to change.\" The \"reason\" isn't a technical reason—it's a **stakeholder reason**. It's a reason rooted in the real world, in the needs of people who use and depend on the software."},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Stakeholder Lens","content":"When evaluating whether a class has multiple responsibilities, ask: \"Who would request changes to this class?\" If different groups of people (stakeholders, departments, roles) would request changes for different reasons, the class likely has multiple responsibilities.","variant":"tip"},"type":"callout"},{"data":{"content":"**The critical insight:**\n\nA class doesn't have multiple responsibilities because it has multiple methods. It has multiple responsibilities when **different forces in the real world can cause it to change**.\n\nConsider a simple analogy: A chef in a restaurant is \"responsible\" for creating dishes. That's one responsibility—even though it involves hundreds of tasks: chopping, sautéing, plating, seasoning. The chef answers to one stakeholder: the culinary vision of the restaurant. If the restaurant's food philosophy changes, the chef adapts. If the accounting system changes, the chef is unaffected.\n\nNow imagine the chef is also responsible for the restaurant's marketing. Suddenly, changes in customer demographics affect the chef's work—not because of food, but because of advertising. The chef now has two responsibilities because two different forces drive change."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"responsibility-vs-function","title":"Responsibility vs. Function","content":[{"data":{"content":"The most common SRP mistake is conflating **responsibility** with **function**. This leads to absurd designs where every method becomes its own class, and simple operations require coordinating dozens of objects.\n\nLet's be explicit about the distinction:"},"type":"text"},{"data":{"rows":[["Definition","A specific action or operation performed by code","An axis of change driven by a stakeholder or actor"],["Granularity","Fine-grained, implementation-level","Coarse-grained, business/domain-level"],["Change Driver","Technical requirements, optimizations","Business needs, policy changes, actor demands"],["Example","\"Calculate shipping cost\"","\"Manage order fulfillment logistics\""],["Who Cares?","Developers implementing the feature","Business stakeholders who own the domain"],["Count Per Class","Many functions is normal and expected","One responsibility per class is the goal"]],"caption":"Responsibility vs Function: The Critical Distinction","headers":["Aspect","Function/Task","Responsibility"]},"type":"table"},{"data":{"content":"**A concrete example:**\n\nConsider an `Employee` class with these methods:\n- `calculatePay()` — Determines salary based on hours, rate, bonuses\n- `generatePayStub()` — Creates a formatted pay statement\n- `calculateTaxWithholding()` — Computes taxes to withhold\n- `updatePayRate()` — Modifies the employee's pay rate\n\nAre these four responsibilities or one?\n\n**They are one responsibility: Payroll Computation.**\n\nAll these methods change for the same reason: when payroll policies change. The CFO's office owns this domain. If tax laws change, if bonus structures evolve, if pay stub formats need updating—the same stakeholder requests all these changes.\n\nNow add this method:\n- `generatePerformanceReport()` — Creates a report for HR reviews\n\n**This is a second responsibility: HR Reporting.**\n\nPerformance report changes are driven by HR policy, not payroll policy. The Chief Human Resources Officer owns this domain. Different stakeholder, different reason to change, different responsibility."},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Over-Splitting Trap","content":"Splitting every function into its own class doesn't follow SRP—it creates a fragmented, unusable codebase. The goal isn't minimizing methods per class; it's ensuring each class serves a single stakeholder concern. A class with 20 methods that all serve one responsibility is better designed than 20 single-method classes each serving fragments of that responsibility.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"axis-of-change","title":"The Axis of Change Model","content":[{"data":{"content":"$6a"},"type":"text"},{"data":{"fileName":"axis-of-change-example","languages":[{"code":"$6b","label":"TypeScript","value":"typescript"},{"code":"$6c","label":"Python","value":"python"},{"code":"$6d","label":"Java","value":"java"}]},"type":"code"},{"data":{"content":"In the example above, the `Order` class is pulled in four different directions:\n\n1. **Pricing policy changes** → Modify `calculateTotal()`\n2. **Database schema changes** → Modify `saveToDatabase()`\n3. **UI/UX redesigns** → Modify `toHtmlReport()`\n4. **Shipping API updates** → Modify `submitToShippingProvider()`\n\nThese represent four different actors (finance, infrastructure, product/design, and operations), and each has independent reasons to request changes. This class is not following SRP—it has four responsibilities."},"type":"text"}],"titleType":"number","titleNumber":3},{"id":"identifying-boundaries","title":"Identifying Responsibility Boundaries","content":[{"data":{"content":"Recognizing responsibility boundaries requires asking the right questions. Here's a systematic approach to identifying whether a class has one or multiple responsibilities:"},"type":"text"},{"data":{"type":"ordered","items":["**Who owns this code?** — Which person, role, or department would \\\"own\\\" changes to this class? If multiple groups would claim ownership of different parts, you have multiple responsibilities.","**What changes together?** — When one method changes, which other methods typically change with it? Methods that change together usually belong to the same responsibility. Methods that change independently suggest separate responsibilities.","**What can I describe in one sentence?** — Try to describe the class's purpose in a single sentence without using \\\"and\\\" or \\\"or.\\\" If you must use conjunctions, the class likely has multiple responsibilities.","**What would I test together?** — Tests that logically group together often indicate a responsibility boundary. If testing one aspect of a class requires completely different fixture setup than another aspect, those aspects may be separate responsibilities.","**What could I reuse independently?** — Parts of a class that could be reused in a different context suggest separate responsibilities. If you find yourself wanting to use only half of a class, it probably has two responsibilities."],"title":{"icon":"Target","text":"Responsibility Boundary Questions","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"Info","title":"The Domain Expert Test","content":"A powerful technique: Explain your class to a domain expert (not a developer). If you find yourself switching contexts or saying \"but it also...\" then you likely have multiple responsibilities. Domain experts naturally think in terms of business responsibilities, not technical functions.","variant":"note"},"type":"callout"},{"data":{"content":"**A practical heuristic:**\n\nConsider the **Newspaper Headline Test**. Imagine a newspaper headline announcing a change to your system:\n\n- *\"Company Updates Discount Policy\"*\n- *\"New Database Engine Deployed\"*\n- *\"Website Redesign Launches\"*\n- *\"New Shipping Partner Integrated\"*\n\nEach headline represents a different stakeholder concern and a different reason to change. If your class would be modified in response to multiple headlines, it has multiple responsibilities.\n\nThe goal is designing classes so that each responds to only one type of headline—one type of real-world event that drives change."},"type":"text"}],"titleType":"number","titleNumber":4},{"id":"common-misconceptions","title":"Common Misconceptions About Responsibility","content":[{"data":{"content":"Let's address the most damaging misconceptions about what constitutes a responsibility:"},"type":"text"},{"data":{"left":[{"data":{"items":["\"One method per class\"","\"One verb per class (Save, Load, Calculate)\"","\"Separate classes for getters and setters\"","\"No class should exceed X lines\"","\"Each layer (Controller, Service, Repository) is a responsibility\"","\"Technical concerns (logging, caching) are responsibilities\""],"title":{"icon":"XCircle","text":"Wrong Interpretations","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["\"One stakeholder/actor per class\"","\"One reason to change per class\"","\"One axis of business requirement change\"","\"Cohesive operations that change together\"","\"A logical grouping owned by one domain\"","\"Business capabilities, not technical tasks\""],"title":{"icon":"CheckCircle","text":"Correct Understanding","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"$6e"},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Real Danger","content":"Over-applying SRP based on misconceptions creates systems with thousands of tiny classes, each doing almost nothing. This introduces massive coordination overhead, obscures business logic across dozens of files, and makes the codebase harder—not easier—to maintain. This is called \"nano-service architecture\" and it's an anti-pattern.","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"granularity-considerations","title":"Granularity: How Fine Is Too Fine?","content":[{"data":{"content":"One of the hardest skills in applying SRP is determining the right level of granularity. Responsibilities exist at multiple levels:\n\n- **System Level**: \"Handle user authentication\"\n- **Module Level**: \"Manage password policies\"\n- **Class Level**: \"Validate password strength\"\n- **Method Level**: \"Check for minimum character count\"\n\nAll of these are valid \"responsibilities\" at their respective levels. The question is: **at what level should SRP be applied?**"},"type":"text"},{"data":{"content":"$6f"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Goldilocks Principle","content":"Seek the granularity that is \"just right\" for your context. Too coarse, and changes ripple unexpectedly. Too fine, and you spend more time coordinating objects than building features. The right level often becomes apparent when you listen to how your team naturally discusses the code.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"summary","title":"Summary: Defining Responsibility","content":[{"data":{"content":"We've explored the nuanced meaning of \"responsibility\" in the Single Responsibility Principle. Let's consolidate the key insights:"},"type":"text"},{"data":{"type":"ordered","items":["**Responsibility ≠ Function** — A responsibility is an axis of change driven by a stakeholder, not a single operation or method.","**One Actor Principle** — A class should be responsible to one, and only one, actor (person, role, or group) who might request changes.","**Change as the Metric** — The test for SRP is not \"how many things does this class do?\" but \"how many reasons could this class change?\"","**Context Matters** — The appropriate granularity of responsibilities depends on team structure, rate of change, and system complexity.","**Avoid Over-Splitting** — Creating too-fine-grained classes based on misconceptions about SRP creates more problems than it solves.","**Domain Language** — Responsibilities should map to business concepts that stakeholders recognize, not technical implementation details."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nUnderstanding responsibility is the first step. The next page explores Robert C. Martin's refined definition of SRP: the **actor-based responsibility definition**. This perspective transforms SRP from a vague guideline into a precise, actionable principle rooted in organizational structure and stakeholder analysis."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand what truly constitutes a responsibility in software design. This foundational understanding will shape how you approach class design throughout your career. Next, we'll explore the actor-based model that gives SRP its full precision and power.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7}],"isLocked":false},{"id":"seed_9c36454751be336c2fe57bcb2fa90554","title":"Actor-Based Responsibility Definition","order":1,"content":null,"isLocked":true},{"id":"seed_d28c7415ea2df6e4167284d91ef68556","title":"Cohesion and Responsibility","order":2,"content":null,"isLocked":true},{"id":"seed_8ddab2abe5e470287a22ca5c835a3535","title":"Common Responsibility Boundaries","order":3,"content":null,"isLocked":true}]}}