The Dependency Inversion Principle

• High-level modules should not depend on low-level modules. Both should depend on abstractions
• Abstractions should not depend on details. Details should depend on abstractions
• Instead of directly depending on concrete implementations, classes should depend on abstractions (e.g., protocols or interfaces)
• This makes code loosely coupled, easier to extend, and more maintainable
• It promotes Dependency Injection, which allows for better testability.

The Interface Segregation Principle

• Clients should not be forced to depend on interfaces they do not use
• A class should only implement methods that are relevant to it
• Instead of having large, monolithic interfaces, we should split them into smaller, more specific interfaces
• This avoids forcing classes to implement unnecessary methods.

The Liskov Substitution Principle

• Subtypes must be substitutable for their base types without altering the correctness of the program.
• If a class inherits from another class, it should be able to replace the base class without breaking functionality
• The derived (sub) class must not remove or change the behavior expected from the base class
• This ensures that polymorphism works correctly and the software remains maintainable.

The Open-Closed Principle

• Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification
• Open for extension – be able to add new functionality to a class withoud modifying it’s existing code
• Closed for modification – once a class is developed and tested, it should not be changed. New functionality should be added via inheritance, interfaces or composition.

The Single Responsibility Principle

• A class should do one thing and therefore it should have only one single reason to change
• This means that a class should have only one responsibility or function in the system
• If a class has multiple responsibilities, changes in one part of the system might require modifications in unrelated parts, making the system harder to maintain and more prone to bugs
• Each responsibility should be handled by a separate class, ensuring that changes in one responsibility do not affect others.