SOLID - Development principles

Object-oriented programming has its principles, and it is not just turning everything into objects and using them when we need them. It's important to create understandable objects.

Question #1
Is it important? Why?

Yes, It's important and makes more sense when the application grows and becomes bigger.
Design principles encourage us to make maintainable and flexible software.

Question #2
How?

In every work, if you have some principles and standards, your project will get a great structure to itself.
Like using a framework, here should follow some principles.

Question #3
So, What is SOLID?

• S: Single responsibility principle
• O: Open/Close principle
• L: Liskov substitution principle
• I: Interface segregation principle
• D: Dependency inversion principle

Question #4
What do they mean?

• S: Single responsibility principle

A class should only have one responsibility.
It should have one reason to change.

Benefits:
Testing: A class with fewer test cases is better.
Lower coupling: Less functionality in a single class will have fewer dependencies.
Organization: Smaller and more well-organized classes are better than monolithic ones. (For example, don't create a single class for both car and its functionality, create two separates class, one for car and one for car functions)

• O: Open/Close principle

Open for extension, close for modification.
We are not allowed to modify existing class codes, because it creates new bugs.
For example, when a new type of car has to implement into the system, you should not modify the car class, the right way is to extend the car class.

• L: Liskov substitution principle

A class and its subclass should be able to be replaced by each other. If you have a car and racing car class, and the racing car class is a subclass of car class, you should be able to change or replace them without disrupting the behavior of the program.

• I: Interface segregation principle

Larger interfaces should be split into smaller ones.
For example, your barber interface consists of cutting the hair, shaving, and washing.
It can happen that you hire someone for just washing and shaving, not cutting hair, and he is not a barber.
So? It's really better if you split it into small pieces, don't put it all in one interface.

• D: Dependency inversion principle

High-level and Low-level modules should both depend on abstraction, not each other. In another form, a class should depend on abstraction.