Single responsibility principle
Every class should have only one reason to change.
Every class should have:
- Only one goal of existence.
- Only one responsibility.
- Only one task to do.
- Only one reason for the modification.
This rule can be applied to methods, functions, classes, modules and packages.
Bestseller dnia w księgarni Złote Myśli
- More readable code.
- More understandable code.
- Lack of god-classes — classes, which do everything (or too much) and change with every change in the application.
- Easier software modification and maintenance.
- A small software change only affects one class.
- The modification only affects the area you want to change. A changer does not touch other areas.
- Less error-prone.
- Many classes.
- E-mail address validator in a separate class (not with user data).
- Phone number validator in a separate class (not with user data).
- Database writer in a separate class (not with saving data).
- Class with address a separate class (not with client data).
All posts from mini project: Learn SOLID and OOP principles:
- 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
- SRP: The Single Responsibility Principle – Robert C. Martin – https://drive.google.com/file/d/0ByOwmqah_nuGNHEtcU5OekdDMkk/view