SOLID Principles | Learn The Principles Of Object Oriented Design

Today we will talk about some principles that help us
to create clean and maintainable software.

These principles are called SOLID Principles.

In the word "SOLID", every character refers to a principle
that will help us to maintain our code and make it cleaner,
So let's get started with the history of "SOLID Principles".

The History Of "SOLID"

The first appearance of SOLID principles was
in 1995 as a newsgroup posting.

And the second appearance was on July 20, 2006,
By Robert C. Martin, in his book "Agile Principles, Patterns, Practices in C#"

That after realizing his previous book "Agile Software Development: Principles, Patterns, Practices"
this book was an award-winning book and helped a lot of java and c++ developers
to understand the concept of Agile Software development.

Single Responsibility Principle

A class should have only one reason to change

This principle tells us to have one responsibility
for each class.

Ok, but why?
Let me explain that for you with a simple example

Imagine we have a person and this person
has two skills, design skills and also development skills,
let's see this in a scheme.

Ok that is good, now this person learned some new skills
as a writer and he wants to add these details.

So now we need to change our skills class that have all his skills,
and add the new skills to it, but now think about it,
is that right to have all skills and all methods in one class?

Absolutely no, because when we need to add or
change skills we need to add these skills into it,
because we have over than one reason to change this class.

Good so what then?
Alright, we can do better, think about separating these skills into separate classes
so now we have a Developer class that has all methods this developer can do,
Also, have another class called Designer that has all methods this designer can do.

So, now if this person wants to add new skills as a writer,
we need only to create a new Writer class that has his skills as a writer.

That will help us to maintain our code and make it understood.

Open Closed Principle

Software entities (classes, modules, functions, etc.) should be open for extension but
closed for modification

Now imagine we have a company, and this company has a range salary for each kind of job
this company has two available positions for a designer and developer.

Let's see that in the code.

Alright, that's good, now this company wants to
add another range salary for a writer,
so now we need to add another "If condition" to check if this is a writer and return the salary.

If you noticed here, we violated the "Open Closed Principle", because here
If we want to add another range of salary, we need to change the code.

But there's another way we can do it without violating the "Open Closed Principle"
by using an interface or abstraction class, like this example here.

So, now with this approach, we can create a Designer Class and Developer Class,
these classes implement the JobPosition interface, which means we will add our salary,
In the new class, then in getSalary at Company class, will return our salary.

That's so much better than the previous way.

Liskov Substitution Principle

Subtypes must be substitutable for their base types

This principle was wroten by Barbara Liskov in 1988

The meaning of this principle is, If we have a class called A and
another class is called B, and B inherits A.

So we can use B instead of A and also the opposite

Interface Segregation Principle

Clients should not be forced to depend on methods they do not use

Let's say we need to create an iPhone interface, that interface has some versions of
Apple iPhone, let's see that in a scheme.

Good, but now we have a problem because the iPhone interface has all the features,
that include Iphone12, IPhone13, iPhone 14,
that will make us have to add the new features in Iphone14
to each iPhone 12 and iPhone 13, That will make a problem
in our code after adding new methods into the iPhone interface.

Let's see the valid approach.

Here, we created an Iphonebase Interface, that contains the base features,
also, we created an abstract class for each version of the iPhone that contains,
the new methods that come with our new iPhone.

Now If we need to create iPhone 15,
we will only create an "abstract" with the new features, and iPhone 15 class
that inherits from the abstract.

Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend
on abstractions

Abstractions should not depend upon details. Details should depend upon
abstractions

This principle says High-level modules should not depend on low-level modules,
low-level modules are the tools that high-level modules use.

Assume we have an ImageFilter class and this class uses BWFilter.

The previous way violates the "Dependency Inversion Principle",
because here, the high level module is ImageFilter and the low level is BWFilter,
and here ImageFilter is dependent on BWFilter.

There's another way to do it, without violating this principle.

That is a valid approach because here, both the high-level module
and the low-level module are dependent on an interface called "Filtera ".

Now, if we want to add another filter we can simply create it,
and make it implements our "Filter" interface.

That's all the principles, I hope you benefit from my post,
If you are interested in these kinds of posts make sure to subscribe
into the Newsletter.