You must have heard the clean phrase code repeatedly while learning to program. Clean code is a mysterious feature that makes your code readable and flexible. With a clean code, you become a knight who is always ready to fight the dragon! “The famous Knight of Clean Code science,” says Martin Fowler.
Any idiot can write code that a computer can understand. Good programmers write code that humans can understand.
But have you ever wondered what makes a code clean or not? Finding dirty code is possible by following Code Code Smell. In programming, the signs that indicate that a code is not clean are called bad odors. These symptoms include:
- Rigidity: It is difficult to change the code
- Fragility: The program code design easily breaks down
- Immobility: Code can hardly be reused. The so-called Usability is the code below
- Viscosity: It isn’t easy to do the right thing in the code!
As soon as you smell these bad odors in your code, it would help if you thought about learning clean code design. To design a clean code, you must follow a series of principles or pottery feet! One of these principles is SOLID. SOLID is based on five principles:
- Single Responsibility Principle or SRP
- Open / Closed Principle or OCP
- L is the Substitution Principle ( LSP )
- I interface S segregation P principle or ISP
- D dependency Inversion P principle _ _
This article will introduce the last principle of SOLID, i.e., the principle of dependence inversion.
What is the principle of dependency inversion?
The Dependency Inversion Principle emphasizes that the top-level modules of the program should not be dependent on the bottom-level modules. Robert Martin, better known as Uncle Bob, says:
A: High-level modules should not be dependent on low-level modules. Both of them (top and bottom level modules) must be dependent on Abstractions.
B: Abstractions should not depend on details. Details must depend on Abstractions.
We have to say that it is a bit difficult to explain this principle, and it seems that Uncle has not been very successful in this regard! We should always use interfaces and abstracts in programming in very, very simple (and still very simple) language.
Consider an electrical outlet. All electrical wiring details are defined on the back of the socket. Such as connectors, tangled wires, and so on. All of these are low-level modules of the power system. The electrical sockets of various electronic devices are also considered high-level modules. By this definition, in the absence of an outlet, to receive electricity from the building wiring, we had to keep somehow the wires of the devices connected to the electrical wiring wires! Therefore, high-level modules (electronic device wires) depended on low-level modules (building wiring).
But thanks to the socket, which is an interface, this dependence is reversed. According to the principles of this interface, the building wiring can connect electricity to devices. All devices must follow the rules to connect to the holes of this socket. They must have a socket or a suitable switch with the type of socket.
An example of the principle of inversion of dependence
In the real programming world, this principle is one of the most widely used principles in object-oriented programming. You are implementing this principle whenever you use Interfaces and Abstract to break program code interdependence.
Like many programmers, in the beginning, you probably connected to a database traditionally and received and sent information from it. That is, you wrote a database connection code between the cluttered code of the program and used it as needed in different places of the program. Different queries can be seen scattered anywhere in your code.
The database driver you used (such as MySQL, SQLServer, Oracle, etc.) as low-level modules, your high-level modules, and the program code were heavily dependent on low-level modules. Imagine what would happen if you wanted to migrate from MySQL to a NoSQL database like MongoDB? Tragedy! You had to find all the dependent queries from place to place and change them one by one.
The correct way is to consider an interface for the database. All different drivers are required to implement this interface. From then on, program code only connects to those relationships. In this way, we have reversed this dependence!
If you want to know more:
Conclusion
Learn about the importance of clean code and how to get it. The signs of a dirty code are called bad code odor. These bad smells are stiffness, fragility, inactivity, and stickiness, each of which has its meaning. One of the requirements for achieving clean code is to follow SOLID principles in coding. In this article, you will get acquainted with the last principle of SOLID principles, namely the principle of inversion of dependence or DIP. Other than the example we gave, what examples do you remember of using the last principle in coding? We are always happy to read your comments!