Wonder why I can’t stop stressing on the important of the SOLID principle, well it has saved me from lots of trouble during software development. Today we will be taking about Dependency Inversion. DI is the last part Of SOLID principle and it is the most overlooked aspect of SOLID, I have seen codes from senior developers breach this principle, have seen Junior developers made a mess of this principle. In order for us not to make a mess of this principle, we need to know what it really means

A. High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g. interfaces).

B. Abstractions should not depend on details. Details (concrete implementations) should depend on abstractions.

Objects are meant to be loose, independent, unfaithful, disloyal, Yeah, I said what I said. Tight coupling will do our codes no good and it is one of the code smells we should try to avoid. Enough of talking, let us get into business.

Let us imagine we are developing an application that will need to persist data somewhere, well many applications make use of database to persist data, and this our imaginary application won’t be an exception. Another issue is selecting the database that is right for our application, since we have so many databases available. After going through selection process, we finally picked MYSQL.

Our application will be written in PHP, Dependency Inversion can be practiced with any object-oriented programming language that supports the use of interface.

Now let us write our code without having dependency inversion principle in mind

class DBConnection
{
public function connect(){
//connection logic goes here
}
}

class User

{
Public function__construct(){
$this->dbConnection = new DBConnection;
}

public function register(){
//logic to insert into the database goes here

}
}


Our application has gone live, and it is working well, then we discovered that the application is getting bigger and we MySQL is not the best choice to use user’s data anymore, we want to switch to NoSQL database. Here comes the trouble, looking at our User class we have already hard couple our DBConnection class with the user class all in the name of composition.

The only way we can change our database driver to a NoSQL database is to go back to the user class and rewrite the codes, that is not a good practice imagine you are dealing thousand line of codes, the painstaking effort you have to go through to make sure your codes do not break. Well this is the price you have to pay for not paying attention to dependency inversion Principle. Let us talk about how our design has broken dependency inversion principle ;

Our User class is depending on the DBConnection class, fine we need to connect to a database and persist data, but with what we have done, we have made the user class to solely rely on using just MySQL as our database, this blind loyalty is a code smell and it is regarded as "TIGHT COUPLING"

So how do we break this blind loyalty between our User class and the Database class