Summary
Principle Name | SOLID Principles |
Acronym | SOLID |
Principle Type | OOP Design Principle |
Purpose | To make code more maintainable, flexible, and easily understandable. |
Related Principles | Single Responsibility Principle(SRP) Open/Closed Principle(OCP) Liskov Substitution Principle(LSP) Interface Segregation Principle(ISP) Dependency Inversion Principle(DIP) |
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 |
---|---|---|
Single Responsibility Principle | SRP | A class should do one thing and do it well. |
Open/Closed Principle | OCP | Software entities should be open for extension, but closed for modification. |
Liskov Substitution Principle | LSP | Objects of superclass should be replaceable with the objects of the subclass without affecting the correctness. |
Interface Segregation Principle | ISP | A class should not be forced to implement interfaces that it does not use. |
Dependency Inversion Principle | 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 |
---|---|---|
Singleton Pattern | Single Responsibility Principle (SRP) | Ensures that a class has only one responsibility while controlling the creation of its singleton instance. |
Factory Method Pattern | Open/Closed Principle (OCP) | Allows for object creation to be extended by introducing new classes, without modifying the factory itself. |
Abstract Factory Pattern | Dependency Inversion Principle (DIP) | Uses abstract interfaces for creating families of related objects, decoupling high-level modules from low-level concrete classes. |
Builder Pattern | Single Responsibility Principle (SRP) | Separates the construction of a complex object from its representation, giving the builder one clear responsibility. |
Prototype Pattern | Liskov Substitution Principle (LSP) | Subclasses of a prototype class can be substituted without affecting functionality, supporting LSP. |
Adapter Pattern | Open/Closed Principle (OCP) Liskov Substitution Principle (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. |
Decorator Pattern | Single Responsibility Principle (SRP) Open/Closed Principle (OCP) | Extends functionality of objects without modifying their code (OCP), while adhering to SRP by separating concerns. |
Strategy Pattern | Single Responsibility Principle (SRP) Open/Closed Principle (OCP) | Encapsulates interchangeable algorithms, allowing behavior to be extended without altering the context class (OCP), while keeping algorithm implementations separated (SRP). |
Observer Pattern | Single Responsibility Principle (SRP) Open/Closed Principle (OCP) | Separates notification logic from business logic (SRP) and allows observers to be added/removed without changing the observable (OCP). |
Composite Pattern | Liskov Substitution Principle (LSP) | Ensures that individual objects and composites can be used interchangeably, following the LSP. |
Command Pattern | Single Responsibility Principle (SRP) Open/Closed Principle (OCP) | Commands encapsulate actions, allowing new commands to be added without modifying existing code (OCP) while each command has a single responsibility (SRP). |
Facade Pattern | Single Responsibility Principle (SRP) | Simplifies the interface of complex subsystems, providing a single, more focused responsibility for client interactions. |
Mediator Pattern | Single Responsibility Principle (SRP) Open/Closed Principle (OCP) | The Mediator centralizes communication between components, adhering to SRP, and new interactions can be introduced without modifying existing code (OCP). |
State Pattern | Single Responsibility Principle (SRP) Open/Closed Principle (OCP) | The state pattern separates behavior based on state, adhering to SRP, and allows adding new states without altering existing classes (OCP). |
Template Method Pattern | Open/Closed Principle (OCP) Liskov Substitution Principle (LSP) | Subclasses can override steps of the algorithm without changing the overall structure (LSP), and the template method allows extending the algorithm without modification (OCP). |
Chain of Responsibility Pattern | Single Responsibility Principle (SRP) Open/Closed Principle (OCP) | Each handler in the chain has one responsibility (SRP), and new handlers can be added without modifying existing ones (OCP). |
Visitor Pattern | Single Responsibility Principle (SRP) Open/Closed Principle (OCP) Liskov Substitution Principle (LSP) | 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). |