SOLID Principles

The principles collected under the slogan SOLID are the most important guidelines at the beginning of learning programming. Their implementation is not only a benefit for the programmer, who creates clear and efficient code, but also for the entire team that continues to work with the finished application. Below is a short description and a link to extensive articles on each of the rules.


S – Single Responsibility Principle (SRP):


A class should have only one reason to change, meaning it should have only one responsibility. This makes the class easier to understand, maintain, and modify.
Example: A class that handles both user input and business logic violates SRP.


O – Open/Closed Principle (OCP):


Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. You should be able to add new functionality without changing existing code.
Example: Achieved through abstractions, inheritance, or interfaces, making it possible to add new behaviors without altering existing code.


L – Liskov Substitution Principle (LSP):


Subtypes should be substitutable for their base types without altering the correctness of the program. A derived class must be usable anywhere its parent class is expected without unexpected behavior.
Example: If a Square class is derived from a Rectangle, it should work with any logic expecting a Rectangle.


I – Interface Segregation Principle (ISP):


Clients should not be forced to depend on interfaces they do not use. It’s better to have many small, specific interfaces than one large, general-purpose interface.
Example: Instead of a single Machine interface for all operations (print, scan, fax), split into smaller, focused interfaces like Printer, Scanner, etc.


D – Dependency Inversion Principle (DIP):


High-level modules should not depend on low-level modules; both should depend on abstractions. Additionally, abstractions should not depend on details, but details should depend on abstractions.
Example: A service class should depend on an interface rather than a concrete class, allowing for flexible implementation changes.