Dependency Inversion Principle

Lets explain this principle with an example. For instance you have an e-commerce site. There are many methods, classes, etc. that do all e-commerce transactions on your site. However, let’s say you do the payment through the API of bank A. For example, let’s say the PaymentMake() method is used when making a request for a payment. Let this method go and make the necessary transactions via the A bank API and draw the fee and give you a return value as payment has been received. Everything works very well, but years later, let’s say you wanted to work through the API system of bank B. Let’s see what you need to do;

You need to go and find and delete the codes related to bank A among all your payment-related codes, or make a comment line in case it comes back and replace the codes of bank B with these codes, right?

If we had created a layer in between and received the required fields with this layer and were transmitting them to the payment layer of the A or B bank through the middleware, we could have added the C or D bank if necessary without making any changes.

In other words, we may have switched to the new system by making a generalization by saying odemeLayer.OdemeMake() instead of aBankasi.OdemeMake() and having our transactions done by using the paymentLayer interface for bank A or B, without making any changes in the code.