SOLID design principles

Tram Ho

SOLID stands for the first 5 letters of the 5 principles of object-oriented design. Help programmers write code that is easy to read, understand, and maintain.

These five design principles include:

  • S : Single-responsibility principle (SRP)
  • O : Open–closed principle (OCP)
  • L : Liskov substitution principle (LSP)
  • I : Interface segregation principle (ISP)
  • D : Dependency inversion principle (DIP)

Content

Single-responsibility principle (SRP)

This design principle is simply understood that a class should have only one task. When a class has too many functions, over time the development of the project, the class also swells and leads to more difficult to develop and maintain.

To understand the principle of SRP, let’s consider the following example

As we can see, the Document class above is both responsible for representing the Document class and responsible for exporting it to different formats.

To follow the SRP design principle, we will separate exportHtml and exportPdf into two separate classes with the Document class.

Open–closed principle (OCP)

Basically, this principle is understood in the sense that we can freely extend a class but we cannot modify it inside that class.

Let’s take an example if we have a good working system with normal login function (user enters email and password), now if we want to extend login system through a third party such as google, github,… how will you do it. To solve this problem, you need to understand that the problem is asking for a new function, not a modification of the existing login function. If you modify the existing login function, it is a violation of the OCP principle.

Modify existing login function => violate OCP design principle

Use the interface and extend the login function by adding a 3rd party login method => satisfying the OCP design principle.

In addition to the login problem, there is another problem with an equivalent solution that is adding a payment method to a system.

Some benefits of applying OCP principles in programming:

  • Extend the functionality of the system, without touching the core of the system.
  • Prevent breaking of system parts by adding new functions.
  • Easy to test.

Liskov substitution principle (LSP)

This principle is understood in the sense that objects of the child class can replace the parent class without changing the correctness of the program.

For example, when we want to write a program to describe birds that can fly, but penguins can’t. So when writing to the penguin function, when calling the penguin’s flight function, we will throw a NoFlyException, thus violating the LSP principle.

Interface segregation principle (ISP)

Instead of using a large interface, let’s separate them into small interfaces with specific purposes. Imagine you have a huge interface with a lot of different methods and when each class implements those interfaces, you have to override all those methods, very inconvenient, right? But if we separate them into interfaces with different purposes, which class needs to use which function, we just need to implement that function, it is very easy to manage interfaces.

With the above example we can see that the Tester class has a method of code that is not compatible with it and is forced to return an exception, to fix this, we will apply the ISP principle and separate the above interface into small interfaces.

As we can see because testers can’t code, we just need to implement Testable interface, so there won’t be any errors.

Dependency inversion principle (DIP)

DIP is considered the most confusing principle of SOLID. The content of this principle says that high-level modules should not depend on low-level modules, but both should depend on abstraction. Interface (abstraction) should not depend on details, but on the contrary (Classes communicate with each other through interface, not through implementation).

For the above code, it still works normally, but it has the problem that Notification directly depends on Email and it violates SRP principle because it has to send email and initialize Email to perform sending email. . Now we will pass Notifications that depend on the interface and not on the Email

So we can see that the Notification class does not depend directly on Email or SMS but it depends on the MessengerInterface interface, with that later we can extend other forms of sending messages besides email and sms.

Conclude

We have learned about SOLID design principles, thank you for following the article. Hope the article can bring useful knowledge to you. See you in the next posts.

Share the news now