Object oriented programming (OOP) is one of the most used programming models and also one of the most effective models to model the real world into the code world. The special properties that make “object-oriented” effective are:

• Abstraction: Create abstract classes that model objects in the real world.
• Encapsulation: Entities of abstract class have separate attribute values.
• Inheritance: Objects can easily inherit and extend each other.
• Polymorphism: A single action can be performed in a variety of ways depending on the specific type of object being called.

These special properties of OOP help us build programs that solve many different specific problems in the real world. Most programmers already know these properties of OOP, but the way to combine these properties to increase the efficiency of the application is not well known. One of the guidelines to help us use OOP more effectively is the SOLID principle. Basically, SOLID is a set of 5 guidelines that have been mentioned for a long time by software developers, then synthesized and stated in principle by Robert C. Martin, also the author of the book. The famous Clean Coder that I have reviewed. These five principles include:

• Single Responsibility principle (SRP).
• Open-Closed principle (OCP).
• Liskov substitution principle (LSP).
• Interface segregation principle (ISP).
• Dependency inversion principle (DIP).

The above principles are stated as follows:

1. SRP – Single responsibility principle

Statement: Each class should only be responsible for a specific task.

If a class of us that undertakes too much responsibility. This makes our code too deeply interlinked and can fail if there are any minor changes. Suppose we have a class like this:

We can see that this Order class has 3 responsibilities that are displaying the order’s information, processing the order and saving the order and in the database. So, later we want to email the order, adding order processing operations makes this class very big. In principle, we should separate 3 classes as follows:

2. OCP – Open-Closed principle

Statement: Do not modify an existing Class, but may extend it by inheritance.

This principle can be understood that classes or functions should be designed to be extended, but closed to avoid direct modification of the source code. This means that the system should be designed to support programmers to extend existing classes to provide additional functionality instead of editing existing code in the system. Here so you can better understand. I want to calculate the total area of ​​the array of geometric blocks as follows:

The code allows us to calculate the area of ​​the rectangle and square. If I want to expand the program now, I want to support more triangles. Now I have to modify the sum function of the AreaCalculator class. This is a violation of the principle, to correct it we need to do the following:

With the new code we have edited in accordance with this principle, if you want to expand to calculate more circles, triangles or whatever, you just need to create ADD a class and implement the Shape interface. Okay, no need to fix the existing code.

3. LSP – Liskov substitution principle

Statement: Instances of a subclass instance can replace parent class objects without causing an error.

This principle is construed as follows. A company has two types of employees: full-time employees, unpaid trainees. For full-time employees, income tax is not required and trainees do not. You have 1 class NhanVien to be the parent class for employees in the company as follows:

This is in violation of this principle because when calling the dongThue () function of the ThucTapSinh class will cause the program to fail. To solve this problem, you need to create an NhanVienCanDongThue interface and what kind of employees need to pay taxes, we will implement it.

4. ISP – Interface segregation principle

Statement: If the Interface is too large, it should be split into smaller interfaces.

For example, you have a common interface for developers.

There, you will find it really absurd when a PHPDeveloper implements interface Developer has to go to codeRuby or codeIOS right. In this case we should split 3 smaller interfaces, the PHPDeveloper implements only the PHPDeveloper interface.

5. DIP – Dependency inversion principle

The last principle, corresponding to the letter D in SOLID. Principle content:

Statement: System components (classes, modules, etc.) should only depend on abstractions, not specific concretions or implementations.

This principle is quite tricky, we consider the following example:

In the Class Driver initialization method we create a vehicle and assign it to the driver. Thus the Driver class is tightly bound to the Car class. Drivers can drive many different vehicles, if the Car class is replaced with another class, the application will not run. We create an abstract definition (interface) or an interface

As such, drivers and cars depend on the Car interface, the second is the specific classes such as BMV, Mercedes depends on the Car interface, so if there are any vehicles that follow. with the definition of Car, the driver can drive.

summary

Above is what I learn about SOLID principles in software development. Actually, at the present time, I still do not really understand and apply effectively and integrity the above principles into the project coding. Hopefully you and your friends in the future can apply SOLID effectively to make the software building better.