Solid principles: Introduction

In this lesson, we will discuss what SOLID principles are, why you should apply them, and on what you will practice in the next lessons.

What are the SOLID principles?

The SOLID principles are five basic principles of how to write a clean code so that you can easily develop it, test it and understand it if someone else would use our code or if we would return to our code for, say, half a year.

These principles were invented by Robert Martin (The Prince’s Bob) famous American programmer.

I will just mention these principles in this lesson and briefly discuss each of them, we will process each rule in successive lessons in turn.

Description of SOLID principles

The five basic principles of the Bob’s are:

Single Responsibility principle – this principle says that each class should be responsible for one particular thing.

Open / Closed principle – that is open to extension and closed to modifications.

Liskov Substitution Principle – in other words, this rule says that the inheriting classes must be 100% compatible with all methods and interfaces.

Interface segregation principle – this rule is very simple says not to create interfaces with methods that the class does not use.

Dependency Inversion principle – is a simple and important principle, all dependencies should depend on abstraction and not on a particular type.

Why is it worth know and apply the SOLID principles?

The SOLID principles are worth adhering, you should adhering them and should make the code testable, cleaner, so that it can be easier to understand, if you write the whole code you will not have a problem to understand it, but the problem will be if the programmer will be attached to your code, who has never seen your code. In some projects, all SOLID principles can not be perfectly adhered to, but if you break only one rule or will be adhered all principles it will be succes.

On what we will be practice on?

For the purpose of explaining the SOLID principles, I have prepared a console program that imitates the operation of the store, I will probably add various functionalities in some lessons so that I would explain some principle, because this program does not have interfaces, and some rules just apply to interfaces, so probably in later I will be adding interfaces or other functionalities to the lessons.

As you can see, the class and its calling looks like one word “terribly !!!”.

We will refactorize this class according to the SOLID principles, if someone continues to work on this program, it would be suicide in advance, we must change it so that it can be easily modified, tested, expanded, etc. how to do it? We will get to that in the next lessons.