Spis treści
Single responsibility principle
Each class should have only one responsibility (one reason to change) — one purpose of existence.
How to use the SRP principle in practice?
Combine into one code, which has the same reason to change. Separate a code that has many reasons to change.
Difficulties with SRP
There are some difficulties with the SRP principle:
- It is not defined what a change is.
- It is not defined what the responsibility is.
- It requires anticipating the future.
Class, function, method, etc. should be responsible for a single business logic on one level of abstraction. (http://adam.wroclaw.pl/2014/12/zasada-pojedynczej-odpowiedzialnosci/)
Classes should be organized to minimize complexity. They should:
- Be small enough to reduce dependencies.
- Be large enough to maximize consistency.
By default, you should choose to group functionality for code separation. (https://sklivvz.com/posts/i-dont-love-the-single-responsibility-principle)
Example
The class book has two responsibilities.
- Has information about itself.
- Print itself.
class Book
{
private string title;
private string content;
public Book(string title, string content)
{
this.title = title;
this.content = content;
}
public void PrintBook()
{
Console.WriteLine(title);
Console.WriteLine(content);
}
}
class Program
{
static void Main(string[] args)
{
Book book = new Book("Interesting title", "Nice content");
book.PrintBook();
}
}
In these changes, I have assigned the responsibility for the book to a separate class.
class Book
{
private string title;
private string content;
public Book(string title, string content)
{
this.title = title;
this.content = content;
}
public string GetBookToPrint()
{
return $"{title}{Environment.NewLine}{content}";
}
}
interface IPrinter
{
void Print(string content);
}
class BookPrinter : IPrinter
{
public void Print(string content)
{
Console.WriteLine(content);
}
}
class Program
{
static void Main(string[] args)
{
IPrinter printer = new BookPrinter();
Book book = new Book("Interesting title", "Nice content");
var bookToPrint = book.GetBookToPrint();
printer.Print(bookToPrint);
}
}
}
All posts from mini project: Learn SOLID and OOP principles:
- SOLID
- SOLID exercises
- S like Single responsibility principle
- SOLID exercises — Kata
- O as Open-closed principle
- L jak Liskov Substitution Principle
- Interface segregation principle
- KISS — Keep it simple, stupid
- DRY — Don’t repeat yourself
- Dependency inversion principle
- SLAP — Single Level of Abstraction Principle
- Composition Over Inheritance
- Encapsulate what changes
- Lod — Law of Demeter
- ES as Exercises of Single responsibility principle
- EO as Exercises of Open/closed principle
- EL as Exercises of Liskov Substitution Principle
- EI as Eexrcises of Interface segregation principle
- ES as Exercises of Dependency Inversion Principle
- Object-oriented programming
- OOP — Object-Oriented Programming — Advice
- OOP — Object Oriented Programming
Sources
Main image
Materials
- Clean Architecture — Robert C. Martin
- https://hackernoon.com/you-dont-understand-the-single-responsibility-principle-abfdd005b137
- https://code.tutsplus.com/tutorials/solid-part-1-the-single-responsibility-principle–net-36074
- http://adam.wroclaw.pl/2014/12/zasada-pojedynczej-odpowiedzialnosci/
- https://sklivvz.com/posts/i-dont-love-the-single-responsibility-principle