Solid

Intro
01
02
Single Responsibility
03
Open/closed principle
04
Liskov Substitution
05
Interface Segregation
06
Dependency inversion

Intro

Intro

Intro
SOLID is an acronym for 5 important design principles when doing OOP (Object Oriented Programming).
These five software development principles are guidelines to follow when building software so that it is easier to scale and maintain. They were made popular by a software engineer, Robert C. Martin.
The intention of these principles is to make software designs more understandable, easier to maintain and easier to extend.

S – Single Responsibility

S – Single Responsibility
In programming, the Single Responsibility Principle states that every module or class should have responsibility over a single part of the functionality provided by the software.
A class should have a single responsibility.
If a Class has many responsibilities, it increases the possibility of bugs because making changes to one of its responsibilities, could affect the other ones without you knowing.

S – Single Responsibility

S – Single Responsibility

O - Open/closed principle

O - Open/closed principle
In programming, the open/closed principle states that software entities (classes, modules, functions, etc.) should be open for extensions, but closed for modification.
Classes should be open for extension, but closed for modification.
This principle aims to extend a Class’s behavior without changing the existing behavior of that Class. This is to avoid causing bugs wherever the Class is being used.

O - Open/closed principle

O - Open/closed principle

L - Liskov Substitution

L - Liskov Substitution
In programming, the Liskov substitution principle states that if S is a subtype of T, then objects of type T may be replaced (or substituted) with objects of type S.
More generally it states that objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
The child Class should be able to process the same requests and deliver the same result as the parent Class or it could deliver a result that is of the same type.

L - Liskov Substitution

I - Interface Segregation

I - Interface Segregation
In programming, the interface segregation principle states that no client should be forced to depend on methods it does not use. Put more simply: Do not add additional functionality to an existing interface by adding new methods. Instead, create a new interface and let your class implement multiple interfaces if needed.
Clients should not be forced to depend on methods that they do not use.
This principle aims at splitting a set of actions into smaller sets so that a Class executes ONLY the set of actions it requires.

I - Interface Segregation

I - Interface Segregation

D - Dependency inversion

D - Dependency inversion
In programming, the dependency inversion principle is a way to decouple software modules.
This principle states that:
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
To comply with this principle, we need to use a design pattern known as a dependency inversion pattern, most often solved by using dependency injection.
Typically, dependency injection is used simply by ‘injecting’ any dependencies of a class through the class’ constructor as an input parameter.

D - Dependency inversion
High-level Module(or Class) - Class that executes an action with a tool.
Low-level Module (or Class) - The tool that is needed to execute the action
Abstraction - Represents an interface that connects the two Classes.
Details - How the tool works

D - Dependency inversion