Summary
Principle Name | SOLID Principles |
Acronym | SOLID |
Principle Type | OOP Design Principle |
Purpose | To make code more maintainable, flexible, and easily understandable. |
Related Principles | ![]() ![]() ![]() ![]() ![]() |
Definition
SOLID principles are a collection of design principles used to make the implementation of software systems more readable, maintainable, flexible(for later changes), and easily understandable.
SOLID Principles refer to a collection of five(5) individual principles, widely used in Object-Oriented Programming(OOP).
The term “SOLID” is derived from the first letter of each of those 5 principles.
The SOLID design principles are five(5) ideas that can help us build a software system that is easy to adapt and extend.
Here are the file(5) principles-
What SOLID Principles are
What SOLID Principles are not
Details of SOLID Principles
We have discussed each of the five(5) principles of SOLID Principles separately, in individual articles. In those separate articles, we are digging deep into each principle and going to very detailed explanation of those principles.
Read the principles in detail using the following links-
Principle | Acronym | Purpose/Tagline |
---|---|---|
![]() | SRP | A class should do one thing and do it well. |
![]() | OCP | Software entities should be open for extension, but closed for modification. |
![]() | LSP | Objects of superclass should be replaceable with the objects of the subclass without affecting the correctness. |
![]() | ISP | A class should not be forced to implement interfaces that it does not use. |
![]() | DIP | High-level modules should not depend on low-level modules, rather both should depend on abstractions. |
Advantages of SOLID
Following and implementing SOLID principles have a huge impact on the source code. These principles contribute to the quality and longevity of the software system project.
Here are a few key advantages we get from SOLID Principles-
Usage in Design Pattern
SOLID Principles are heavily used in the implementation of design patterns, providing the structure and flexibility needed for clean, maintainable code.
Here is a list of design patterns that use one or more of the SOLID Principles.
Design Pattern | Related SOLID Principle(s) | Explanation |
---|---|---|
![]() | ![]() | Ensures that a class has only one responsibility while controlling the creation of its singleton instance. |
![]() | ![]() | Allows for object creation to be extended by introducing new classes, without modifying the factory itself. |
![]() | ![]() | Uses abstract interfaces for creating families of related objects, decoupling high-level modules from low-level concrete classes. |
![]() | ![]() | Separates the construction of a complex object from its representation, giving the builder one clear responsibility. |
![]() | ![]() | Subclasses of a prototype class can be substituted without affecting functionality, supporting LSP. |
![]() | ![]() ![]() | The Adapter class can introduce new behaviors without modifying existing code (OCP) and follows LSP by ensuring the adapted interface can substitute its original. |
![]() | ![]() ![]() | Extends functionality of objects without modifying their code (OCP), while adhering to SRP by separating concerns. |
![]() | ![]() ![]() | Encapsulates interchangeable algorithms, allowing behavior to be extended without altering the context class (OCP), while keeping algorithm implementations separated (SRP). |
![]() | ![]() ![]() | Separates notification logic from business logic (SRP) and allows observers to be added/removed without changing the observable (OCP). |
![]() | ![]() | Ensures that individual objects and composites can be used interchangeably, following the LSP. |
![]() | ![]() ![]() | Commands encapsulate actions, allowing new commands to be added without modifying existing code (OCP) while each command has a single responsibility (SRP). |
![]() | ![]() | Simplifies the interface of complex subsystems, providing a single, more focused responsibility for client interactions. |
![]() | ![]() ![]() | The Mediator centralizes communication between components, adhering to SRP, and new interactions can be introduced without modifying existing code (OCP). |
![]() | ![]() ![]() | The state pattern separates behavior based on state, adhering to SRP, and allows adding new states without altering existing classes (OCP). |
![]() | ![]() ![]() | Subclasses can override steps of the algorithm without changing the overall structure (LSP), and the template method allows extending the algorithm without modification (OCP). |
![]() | ![]() ![]() | Each handler in the chain has one responsibility (SRP), and new handlers can be added without modifying existing ones (OCP). |
![]() | ![]() ![]() ![]() | Visitor lets you add new operations to a class hierarchy without altering the hierarchy itself (OCP), each visitor class has a single responsibility (SRP), and visitors can operate on objects in a consistent way (LSP). |