Upgrade Your Development Skills: Introduction to SOLID Principles
Tags: beginners, programming, architecture, codenewbie
Published: 2023-01-26 08:26:56

A clear distinction between junior and senior developers is how well senior developers future-proof their programs; one way of achieving this is to use a well-known code or rules, like SOLID principles, which Robert C. Martin developed in his essay, "Design Principles and Design Patterns."

SOLID is an acronym for single responsibility, open-closed, Liskov substitution, interface segregation, and dependency inversion principle, and it's important to state that SOLID is mainly for OOP.

It's important to recall that this is an introduction; thus, I will use easy scenarios, and the examples shown are for learning purposes only and not for commercial use. Lastly, I'll use sudo code to make it reachable to most people.

---

## Single Responsibility Principle
The single responsibility principle states, "A class should have only one reason to change." According to the previous state, each class is responsible for only one part during the software lifespan.

To kick off the article, I'll create a simple User class:

```
class User {
    function profile()
    function login()
    function register()
    function sendVerificationEmail()
}
```
As we can see, the class is responsible for more than one part, and my way of applying the principles is the following:

```
class User {
    function profile()
}

class Authentication {
    function login()
}

class Signup {
    function register()
    function sendVerificationEmail()
}
```
We now have three classes, each responsible for only one part.

---

## Open Closed Principle
The open-closed principle states, "A class should be open to extension but closed to modifying." According to the previous state, each class should be written in a way that allows the addition of functionality but does not allow alteration of its core.

To demonstrate a demo of this principle, I'll create another User class but this time, it will have a variable called `type`:

```
class User {
    var type

    constructor(var type) {
        this.type = type
    }

    function doSomething() {
      if(type == "normal") {
        // ...
      } else if(type == "professional") {
        // ...
      }
    }

    // ...
}

User normalUser = new User("normal")
User professionalUser = new User("professional")
```
The class is open for modification because `type` has a direct influence on the class's functionality; this is an example of why we need the open-closed principle. Let's see an example of how to apply the principle here:

```
abstract class User {
    abstract function doSomething()
}

class NormalUser Inherits User {
    function doSomething() {
      // ...
    }
}

class ProfessionalUser Inherits User {
    function doSomething() {
      // ...
    }
}

User normalUser = new NormalUser()
User professionalUser = new ProfessionalUser()
```
By implementing the principle, we can write a more precise functionality.

---

## Liskov Substitution Principle
The Liskov substitution principle states, "if S is a subtype of T, then objects of type T may be replaced with objects of type S" Liskov substitution is better explained with an example:

```
abstract class Employee {
    abstract function getBonus()
}

class HardWorkingEmployee Inherits Employee {
    function getBonus() {
        // ...
    }
}

class LackingEmployee Inherits Employee {
    function getBonus() {
        Error
    }
}
```
And now, to instantiate an instance of `HardWorkingEmployee` class:

```
Employee employee = new HardWorkingEmloyee()
employee.getBonus()
```
The example above would work perfectly, now let's change `HardWorkingEmployee` with `LackingEmployee`:

```
employee = new LackingEmployee()
employee.getBonus()
```
The example above would not work because, `LackingEmployee` does not implement `bonus` function, even though they both are of type `Employee`, and that is a violation of the Liskov Substitution; an easy fix for this situation is the following:

```
abstract class Employee {
    // ...
}

interface EligableForBonus {
    function getBonus()
}

class HardWorkingEmployee Inherits Employee, EligableForBonus {
    function getBonus() {
        // ...
    }
}

class LackingEmployee Inherits Employee {
    // ...
}
```
Now `LackingEmployee` does not inherit any non-implemented functionality.

---

## Interface Segregation Principle
The interface segregation principle states, "Clients should not be forced to depend upon interfaces that they do not use." It means that when a class inherits a parent, it should implement all of its functionality.

```
interface UserFunctions {
    function function1()
    function function2()
    function function3()
    function function4()
}

class User inherits UserFunctions {
    function function1() {
      // ..
    }

    function function2() {
      // ..
    }

    function function3() {
      // ..
    }

    function function4() {
      Error
    }
}
```
The User class does not implement `function4` and thus, it violates the interface segregation principle; one way of fixing it is the following:

```
interface CoreUserFunctions {
    function function1()
    function function2()
    function function3()
}

interface ExtraUserFunctions {
    function function4()
}

class BasicUser inherits UserFunctions {
    function function1() {
      // ..
    }

    function function2() {
      // ..
    }

    function function3() {
      // ..
    }
}

class UpgradedUser inherits UserFunctions, ExtraUserFunctions {
    function function1() {
      // ..
    }

    function function2() {
      // ..
    }

    function function3() {
      // ..
    }

    function function4() {
      // ..
    }
}
```
Now we have `BasicUser` and `UpgradedUser` and both fully implement what they inherit.

---

## Dependency Inversion Principle
The Dependency Inversion Principle states, "The interaction between high level and low level modules should be thought of as an abstract interaction between them." It means that if we have interactions between high-level and low-level modules or classes, we should add a middle layer because they both operate at different levels of complexity. 
```
class DataAccesslayer {
    function saveToDatabase(data) {
        // ...
    }
}

class User {
    DataAccesslayer dataAccesslayer
    dataAccesslayer.saveToDatabase(data)
}
```
The example above does not implement the Dependency inversion principle, thus any modification to `DataAccessLayer` might means we need to modify `User` class also, a better implementation would be like this:

```
interface DataAccesslayerInterface {
    function saveToDatabase(data)
}

class DataAccesslayer inherits DataAccesslayerInterface {
    function saveToDatabase(data) {
        // ...
    }
}

class User {
    DataAccesslayerInterface dataAccesslayer
    dataAccesslayer.saveToDatabase(data)
}
```
Now we have an abstraction layer, which means that modification on `DataAccesslayer` will no longer need modification on User class because the abstraction layer does not change; thus function signature does not change