Solid. Is It Still Useful In 2021?
Tags: typescript, javascript, beginners, codequality
Published: 2021-04-03 22:52:30

## Why Even Bother?
In the software development world, there are 2 extremes.
- People who don't follow best practices.
- People who follow them to the extreme.

![SpongBob Gif](https://media.giphy.com/media/3o7aCTPPm4OHfRLSH6/giphy.gif)

If you are lazy like me you mostly don't follow best-practices because **[YAGNI(You aren't gonna need it)](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it#:~:text=%22You%20aren't%20gonna%20need,add%20functionality%20until%20deemed%20necessary.)** but if you are like me you mostly do follow best-practices like **SOLID Design Principles**.

**Wait. Why am I on both sides?** Because I follow both depending on what I am doing. If it's simple, limited/scoped, and predictable then who needs to overthink about best practices but if it's complex, may-become-complex, should be scalable and maintainable then yeah, we need best practices.

If you are building a system that would need changes in the future then you are going to be happy about how **SOLID** can make your life easy.

## What is SOLID?
SOLID is an acronym for 5 principles
- **S.**  :point_right: **[Single Responsibility](https://dev.to/huzaifa99/why-you-should-be-following-the-single-responsibility-principle-1h2a)**
- **O.**  :point_right: **[Open/Close](https://dev.to/huzaifa99/explained-open-close-principle-in-2-minutes-29dd)**
- **L.**  :point_right: **[Liskov Substitution](https://dev.to/huzaifa99/is-the-liskov-substitution-principle-really-useful-3oce)**
- **I.**    :point_right: **[Interface Segregation](https://dev.to/huzaifa99/is-it-practical-to-use-interface-segregation-principle-3ojl)**
- **D.** :point_right: **[Dependency Inversion](https://dev.to/huzaifa99/why-the-dependency-inversion-principle-is-worth-using-opj)**

They aim to make your code manageable, maintainable, and scalable along with other benefits.

#### Note
They are not Rules, but best practices.

### The Person Behind SOLID
This was in the year 2000. **[Robert C. Martin](https://en.wikipedia.org/wiki/Robert_C._Martin)** first introduced SOLID as a subset of different design principles in his paper ***Design Principles and Design Patterns***.

Design principles and patterns are different, **SOLID** are principles.

## So What Do The Principles Mean?
Each SOLID principle aims to achieve a certain goal by following a certain rule. 

### 1. Single Responsibility Principle
It aims to separate behaviors or concerns. Meaning that every piece of code should have a specific purpose of existence and it should be used for that purpose only. 
#### Example
The following function should only validate a user given their id.
```javascript
function validateUser(userId){
    // will validate user with their userId
}
```
For a complete reference, check out the **[Single Responsibility Principle](https://dev.to/huzaifa99/why-you-should-be-following-the-single-responsibility-principle-1h2a)** in detail.
 
### 2. Open/Close Principle
The goal is to prevent those situations in which changing a piece of code from a module also requires us to update all depending modules. Basically, we don't allow new code to make changes to our old code. 

We can ***extend*** code but not ***modify*** it. One real-life use case is of those softwares that have backward compatibility.

#### Example
A typescript example
```javascript
interface PaymentMethod {
  pay() : boolean
}

class Cash implements PaymentMethod {
  public pay(){
    // handle cash pay logic here
  }
}

function makePayment(payMethod: PaymentMethod) {
  if(payMethod.pay()){
    return true;
  }
  return false;
}
```
In the above code if we want to add credit card payment all we have to do is add the following code (along with the actual implementation) and it will work just fine
```javascript
class CreditCard implements PaymentMethod {
  public pay(){
    // handle credit pay logic here
  }
}

```
For a complete reference, check out my other article on **[Open/Close Principle](https://dev.to/huzaifa99/explained-open-close-principle-in-2-minutes-29dd)**.


### 3. Liskov Substitution Principle
What this principle tells us is that if we replace an instance of a child class with a parent class, our code should still work fine without breaking or having side effects. 

#### Example
```javascript
class Printer{
    function changeSettings(){
        // common functionality
    }

    function print(){
        // common functionality
    }
}

class LaserPrinter extends Printer{
    function changeSettings(){
        // ... Laser Printer specific code
    }

    function print(){
        // ... Laser Printer specific code
    }
}

class _3DPrinter extends Printer{
    function changeSettings(){
        // ... 3D printer specific code
    }

    function print(){
        // ... 3D printer specific code
    }
}
```
This principle however has its limitations some of which I discussed in its own separate article. See **[Liskov Substitution Principle](https://dev.to/huzaifa99/is-the-liskov-substitution-principle-really-useful-3oce)** for an example of its limitations.
 

### 4. Interface Segregation Principle
This principle aim's to use role interfaces (or role modules in general) which are designed for a specific purpose and should only be used for those. It says
> Clients Should Not Be Forced To Depend Upon Interfaces That They Do Not Use.

This principle solves some of the issues with the Interface Segregation Principle like the Bird example I mentioned in my article on **[Liskov Substitution Principle](https://dev.to/huzaifa99/is-the-liskov-substitution-principle-really-useful-3oce)**

#### Example
This is a typescript example but still not too difficult to understand.
```typescript
interface BirdFly{
    fly(): void;
}

interface BirdWalk{
    walk(): void;
}

class Duck implement BirdFly, BirdWalk{
    fly(){
        // Duck can fly
    }   
    walk(){
        // Duck can walk
    }
}

class Ostrich implement BirdWalk{
    walk(){
        // Ostrich can walk
    }
} 
```
For a complete reference, check out the **[Interface Segregation Principle](https://dev.to/huzaifa99/is-it-practical-to-use-interface-segregation-principle-3ojl)** in detail.

### 5. Dependency Inversion Principle
It focuses on using abstraction or facade/wrapper patterns to hide details of low-level modules from their high-level implementation.

We basically create wrapper classes that sit in between high-level and low-level modules. This helps a lot if the low-level implementations are different from each other.

#### Example
Again a typescript example
```typescript
interface Payment {
    pay(): boolean
}

// (Wrapper/Abstraction around cash payment)
class CashHandler implements Payment {
    constructor(user){
        this.user = user
        this.CashPayment = new CashPayment();
    }

    pay(amount){
        this.CashPayment.pay(amount)
    }
}

// (low-level module)
class CashPayment {
    public pay(amount){
        // handle cash payment logic
    }
}

// (High-level Module)
function makePayment(amount: number, paymentMethod: Payment){
    if(paymentMethod.pay(amount)){
        return true;
    }
    return false;
}
```
For a complete reference, check out the **[Dependency Inversion Principle](https://dev.to/huzaifa99/why-the-dependency-inversion-principle-is-worth-using-opj)** in detail.

## When To Use What And Avoid What
Now that we know a brief about each principle, we will look at when to use and avoid them.

|                       | Use                                                                                                | Avoid                                                                                                                                                             |
|-----------------------|----------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Single Responsibility** | For Scalable and Maintainable Code.                                                                 | When too much Fragmentation occurs without predictable future changes.                                                                                           |
| **Open Close**            | To prevent old code from breaking due to a new one.                                                   | When over-engineering.                                                                                                                                            |
| **Liskov Substitution**     | Parent/Child used interchangeably without breaking.                                                 | When substitutions do not make sense. (Bird example)                                                                                                            |
| **Interface Segregation** | For Role-specific interfaces.                                                                          | When difficult to aggregate  (due to a lot of modules) from segregation.                                                                                         |
| **Dependency Inversion**  | For different low-level implementations. | When different implementations of a low-level module are not needed,  like the String class in most languages are not changed because it's not needed to mostly. |

These are mostly the reasons and you can disagree but it all comes down to what you are dealing with.

## Is SOLID Still Useful in 2021?
Ask yourself. Is there a language that does everything with one line of code?
```javascript
do_everything();
```

I guess not, unless you or someone makes a language that uses less code than python and does everything with one line of code, you do need **SOLID** design principles.

Of course, there are extremes and cases where it's just not possible to implement **SOLID**, but if you are comfortable and can use SOLID then you probably should.

---
### Conclusion
So, what's your take on this? Do you follow an approach similar to mine? Be sure to give this article a :sparkling_heart: if you like it.