## What is SOLID?

**SOLID** is an acronym representing five crucial principles of object-oriented design programming. It was introduced by [Robert C. Martin](https://en.wikipedia.org/wiki/Robert_C._Martin), with the aim of guiding the construction of flexible, understandable, and maintainable source code.

**S** – Single Responsibility Principle  
**O** – Open Closed Principle  
**L** – Liskov Substitution Principle  
**I**– Interface Segregation Principle  
**D** – Dependency Inversion Principle

The **SOLID** principles are not an absolute solution for all problems, but they provide guidance and fundamental principles for building source code that is easy to maintain and extend.

## Problems SOLID solves in Software Development

1. **Functional Entanglement**
Functional Entanglement refers to a situation during software development in which the responsibilities and functions of different components or modules are not clearly separated. It occurs when the logic of multiple concerns or features become intertwined, making it difficult to understand, maintain, and modify the codebase. This lack of separation can lead to various problems during software development.

2. **Rigidity**
Rigidity in software development refers to a situation where the codebase is inflexible and difficult to modify. This lack of adaptability can arise from design choices, architectural decisions, or coding practices that make it challenging to implement changes or add new features. Rigidity is one of the key issues addressed by software engineering principles and methodologies to enhance the maintainability and scalability of a software system.

3. **Low Reusability**
Low Reusability in software development refers to a situation in which code components, modules, or functions are not designed or structured in a way that promotes easy reuse across other parts. of software systems or in other projects. When code lacks reusability, developers face challenges in leveraging existing solutions for similar or related tasks, leading to increased development effort, duplicate code, and reduced overall efficiency.

4. **Difficulty in Extensibility**
Difficulty in Extensibility in software development refers to challenges faced when attempting to add new features, functionalities, or modifications to a software system. When a system lacks proper design and architectural principles that support easy extensibility, developers may find it cumbersome to adapt the system to changing requirements or incorporate new capabilities.

### S - Single Responsibility Principle
**Original definition**: 

> There should never be more than one reason for a class to change.

If you design a class with multiple responsibilities or 'reasons to change,' you will be required to modify the same code whenever any of those responsibilities needs to change. This not only elevates the risk of unintentionally disrupting one feature while making changes but also goes against the principle of having a single reason to modify a class.

![img](https://easymock-blog-prod-qovya.s3.ap-southeast-1.amazonaws.com/254c67c5-d163-510c-976b-23559e52909b.png)

Imagine when you need to replace or repair a saw blade, you need to disassemble the parts to do so and then reassemble them. This hides the risk that other components may not operate smoothly or worse, cannot be used anymore, which will not happen if the SRP is followed.

**New definition**: 

> Each module should do one thing and do it well.

This principle is closely related to the topic of high cohesion. Essentially, your code should not mix multiple roles or purposes together.

### O - Open/Closed Principle
**Original definition**: 

> Software entities should be open for extension, but closed for modification.

In some design paradigms, you can create classes and extend them (by creating a subclass), but modifying the original class is restricted. The idea of keeping things "open for extension" is to minimize reliance on the class author. Constantly seeking modifications from the original author or delving into the class to make changes can be impractical. Additionally, open modification tends to introduce multiple concerns into a class, violating the single responsibility principle.

![img](https://easymock-blog-prod-qovya.s3.ap-southeast-1.amazonaws.com/02360ff3-1a89-50e1-86d8-547b6d864f4e.png)
**New definition**: 

> You should be able to use and add to a module without rewriting it.

The Open/Closed Principle is evident in Visual Studio Code's extension system. VS Code is open for extension, providing a well-defined API for developers to add new features without modifying the core codebase. This allows for a diverse ecosystem of extensions, each contributing to VS Code's functionality without altering its original source code, showcasing the principle of being closed for modification.

### L - Liskov Substitution Principle
**Original definition**: 

> If S is asubtype of T, then objects of type T may be replaced with objects of type S without altering any of the desirable properties of the program.

This principle refers to objects of a superclass should be interchangeable with objects of its subclasses without impacting the program's correctness. In frontend development, LSP extends to derived components replacing base components seamlessly, maintaining expected behavior. Derived components should support the same props, methods, and behavior as the base component, with added context-specific features. Adhering to LSP fosters interchangeable components, enhancing reusability, modularity, and maintainability.

![img](https://easymock-blog-prod-qovya.s3.ap-southeast-1.amazonaws.com/2c171c1a-5eed-52f5-9901-c01e5855eaa3.png)
**New definition**: 

> You should be able to substitute one thing for another if those things are declared to behave the same way.

This principle advocates for consistent contracts among components, simplifying reasoning and collaboration across diverse components in the application.

### I - Interface Segregation Principle
**Original Definition**: 

> Many client-specific interfaces are better than one general-purpose interface.

This principle refers to the importance of keeping interfaces slim and relevant to the clients that implement them. It's one of the SOLID principles, a set of design principles in object-oriented software development aimed at making software designs more understandable, flexible, and maintainable.

![img](https://easymock-blog-prod-qovya.s3.ap-southeast-1.amazonaws.com/065dff28-2497-5bcb-a255-9fcb1c5ad598.png)
**New Definition**: 

> Don't show your clients more than they need to see.

Consolidating interfaces can introduce complexity to individual objects, resulting in ambiguity regarding functions and tasks not explicitly associated with the object's construction. This goes against the principles of SOLID, particularly the Single Responsibility Principle, as it may lead to unclear and entangled responsibilities within the codebase. Objects should not be forced to depend upon interfaces that they don't use.

### D - Dependency Inversion Principle
**Original definition**: 

> Depend upon abstractions, not concretions.

This principle refers to the following two principles:
- High-level modules should not depend on low-level modules. Both should depend on abstraction.
- Interface (abstraction) should not depend on details, but the opposite. (Classes communicate with each other through interfaces, not through implementations.)

![img](https://easymock-blog-prod-qovya.s3.ap-southeast-1.amazonaws.com/e678cc67-6f75-52c2-a957-241b0d270f52.png)
**New definition**: 

> Depend upon abstractions, not concretions.

To make it easier to understand, look at the electric lights in your house. Here, the high-level module is the electrical outlet, the main interface is the tail light, and the two low-level modules are the light bulb and the fluorescent light bulb.

These two modules both inherit the circular bulb interface. We can easily change the two types of bulbs because the high-level module (electrical socket) only cares about the interface (round bulb), not the implementation (circular or fluorescent bulbs).


## Conclusion
To restate "modern SOLID" one more time:
- Don't surprise the people who read your code.
- Don't surprise the people who use your code.
- Don't overwhelm the people who read your code.
- Use sane boundaries for your code.
- Use the right level of coupling—keep things together that belong together, and keep them apart if they belong apart.

Good code is good code—that's not going to change, and SOLID is a, well, solid basis to practice that!

## Reference document

To learn more about SOLID principles and their introduction by Robert C. Martin, you can refer to his works such as "[Design Principles and Design Patterns](https://staff.cs.utu.fi/~jounsmed/doos_06/material/DesignPrinciplesAndPatterns.pdf)" or "[Clean Code: A Handbook of Agile Software Craftsmanship](https://cuongquach.com/ebook-clean-code-pdf-download-free.html)".

Understanding SOLID is the key to effective source code development, while recognizing the limitations and obstacles in the process of applying SOLID.

SOLID principles: Efficient Software Development Guide

Quan Huynh

patterns

EazyMock

MockAPI

Guide

Blogs

NextFeature

system-design

architecture

hex-arch

Mastering

Monads

Functional

animation

Programming

Tanstack

React

principles

Programing

Recursion

FunctionalTest

SmokeTest

UnitTest

SystemTest

SanityTest

TEQNOLOGICAL

EAZYMOCK

Pick a tag

SOLID principles: Efficient Software Development Guide