SOLID Principles

What are SOLID Design Principles?

SOLID is an acronym that stands for:

• Single Responsibility Principle (SRP)
• Open-Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

 So, what is SOLID and how does it help us write better code? Simply put, Martin and Feathers’ design principles encourage us to create more maintainable, understandable, and flexible software. Consequently, as our applications grow in size, we can reduce their complexity and save ourselves a lot of headaches further down the road!

1. Single Responsibility Principle (SRP):
• Definition: A class should have only one reason to change, meaning that it should have only one responsibility or job.
• Implications:
• Each class should encapsulate a single functionality or responsibility.
• A class should not be forced to change for more than one reason.
2. Open/Closed Principle (OCP):
• Definition: Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
• Implications:
• New functionality should be added through extensions (e.g., inheritance, interfaces) without modifying existing code.
• Existing code should be closed for modification to prevent unintended side effects.
3. Liskov Substitution Principle (LSP):
• Definition: Subtypes must be substitutable for their base types without altering the correctness of the program.
• Implications:
• Derived classes should extend the behavior of the base class without changing its contract.
• Code that uses a base class should be able to use its derived classes without knowing it.
4. Interface Segregation Principle (ISP):
• Definition: A class should not be forced to implement interfaces it does not use. Clients should not be forced to depend on interfaces they do not use.
• Implications:
• Interfaces should be small and specific to the needs of the classes that implement them.
• Clients should not be burdened with methods they do not need.
5. Dependency Inversion Principle (DIP):
• Definition: 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.
• Implications:
• Depend on abstractions (e.g., interfaces) rather than concrete implementations.
• High-level modules and low-level modules should both depend on the same abstractions.