Single responsibility principle
The single responsibility principle is a software design principle that gives a component one focused responsibility and one primary reason to change.
Software Design for Python Programmers
The Single Responsibility Principle states that a class should have one primary responsibility and remain cohesive around it.
- How it is used
- Organizes classes so each has one primary responsibility and remains easy to use and maintain.
- How deep it goes
- Defines cohesion and demonstrates responsibility allocation, while deferring broader design tradeoffs to iterative development.
- Examples
- Uses Python Book and Catalogue classes, catalogue searches, wildcard-like empty attributes, and concrete search output.
- What you can do after
- Evaluate class designs by identifying whether their data and methods serve one clear primary purpose.
Read how Software Design for Python Programmers explains single responsibility principle →
The Art of Code
The Single Responsibility Principle is an object-oriented design principle stating that a class should have only one reason to change.
- How it is used
- Guides method and class decomposition toward maintainable code with a clear, readable story.
- How deep it goes
- Defines the principle and develops practical boundaries, but stops short of prescribing a universal responsibility size.
- Examples
- Uses method length, single-field validation, user registration, dense eligibility conditions, and deeply nested permission logic.
- What you can do after
- Apply SRP through judgment by splitting code when responsibility, length, or cognitive complexity obscures its story.
Read how The Art of Code explains single responsibility principle →
Object-Oriented Software Design in C++
A design principle stating that a class should have one major responsibility.
- How it is used
- Guides class design during iterative design, coding, and testing.
- How deep it goes
- Defines cohesion and demonstrates it with Book and Catalogue, while cautioning against unnecessary class proliferation.
- Examples
- Uses an overloaded automobile class and a tested Book–Catalogue search application.
- What you can do after
- Build cohesive C++ classes, separate responsibilities, and test their behavior through small application iterations.
Read how Object-Oriented Software Design in C++ explains single responsibility principle →
.NET MAUI in Action
The single-responsibility principle is a software design principle stating that a component should have one primary reason to change.
- How it is used
- Organizes .NET MAUI applications by separating UI, presentation logic, and business logic.
- How deep it goes
- Defines one-purpose classes and methods, then works through responsibility boundaries and their maintenance and testing effects.
- Examples
- Uses MauiStockTake, a car database application, injected services, bound properties, commands, and UI-versus-business-logic comparisons.
- What you can do after
- Apply it via MVVM to separate UI state and behavior from business operations, improving maintainability and testability.
Read how .NET MAUI in Action explains single responsibility principle →
Unit Testing Principles, Practices, and Patterns
The Single Responsibility Principle states that a class or module should have one responsibility and one reason to change.
- How it is used
- Guides refactoring toward testable units by separating business logic from orchestration and external communication.
- How deep it goes
- Explains responsibility separation through dependency examples, Humble Objects, and code depth versus width, without prescribing exhaustive design rules.
- Examples
- Uses concrete-class mocking, difficult dependencies, extracted logic, functional cores, domain layers, controllers, and presenters as examples.
- What you can do after
- Refactor mixed classes into focused domain logic and simpler orchestration components that are easier to test.
Read how Unit Testing Principles, Practices, and Patterns explains single responsibility principle →
ASP.NET Core in Action, 3e
The single-responsibility principle is a design principle stating that a class should have responsibility for one piece of functionality and change only when that functionality changes.
- How it is used
- Combines focused services into a complete application while keeping each class centered on one responsibility.
- How deep it goes
- Explains the definition, applies it to e-commerce services, and connects it to dependency construction without detailing implementation registration.
- Examples
- Uses TaxCalculator, ShippingCostService, and OrderTotalCalculator in an e-commerce order calculation.
- What you can do after
- Apply SRP by separating tax, shipping, and order-total responsibilities into focused services.
Read how ASP.NET Core in Action, 3e explains single responsibility principle →
GitHub Actions in Action: Continuous integration and delivery for DevOps
The single responsibility principle is a software design principle stating that a component should have one primary responsibility and one reason to change.
- How it is used
- Guides the design of focused GitHub Actions and workflow files that remain easier to maintain, review, and audit.
- How deep it goes
- Explains practical boundaries for actions, workflows, and jobs, while treating the principle as guidance rather than an absolute rule.
- Examples
- Uses focused shared actions, purpose-specific workflow files, machine-distributed jobs, development-cycle events, and production-review boundaries.
- What you can do after
- Apply it via GitHub Actions by dividing automation into focused actions, workflows, and justified jobs.
Related concepts
- principlekind of · A principle is a general rule, guideline, or value that guides decisions, behavior, or judgments.
- cohesive classimplemented by · A class whose methods and instance variables collectively serve one closely related primary responsibility.
- SOLID principleskind of · The SOLID principles are five object-oriented software-design principles concerning single responsibility, openness to extension, substitutability, interface segregation, and dependency inversion.
- separation of concernsimplements · Separation of concerns is a design principle that organizes a system so distinct responsibilities are handled by separate, independently manageable parts.
- functionconfigures · A function is a defined operation that maps inputs to outputs and, when implemented as a callable program unit, may also produce effects.
- pipeline componentimplemented by · A pipeline component is a discrete, executable stage in a data or machine-learning workflow that performs an operation and may consume or produce data artifacts.
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.