Press "Enter" to skip to content

Dependency Inversion Principle in C# – DIP

Hi everyone, welcome to SOLID principles! Todays topic is Dependency inversion principle!

Here is the basic sentences of this principle:

  1. High-level modules should not be connected to low-level modules. Both must depend on abstract concepts.
  2. Abstract concepts should not depend on details. Details must be based on abstract concepts.

Of course, we will first apply these rules to daily life. I’ve always said that the design principles applied in the software architecture are inspired by life itself. Then let’s look at our life and let us see how easy these two substances are, which seem to be difficult to comprehend.

Now if I tell you that the furniture is a house fixed to the floor; Would you think this house was effective? How much sense can a house that you can’t even move? It’s obvious that there’s a design problem here, isn’t it?

Let’s continue with a similar example. Imagine changing the electrical installation when the bulb in your house exploded! So the large module (electrical wiring) should not be connected to the small module (bulb)! Both should be connected to the abstract grip (lamp veduy and bulb-). Moreover, how many watts of light bulb (detail), the lamp part of the lamp (abstract) is concerned? I do not think so.

Ok, these examples are enough i think:) Lets coding!

According to the scenario we will use in this example; You already have a web service, and this service uses the XML format for data sharing. Let’s first see a poorly designed structure and then discuss why this is bad.

Our code’s pretty good. It’s okay up here. However, after a day JSON (JavaScript Object Notation), a new data sharing format will be removed and you have to change the entire infrastructure. So do you think this architecture would be easy?

The high module in this architecture is the ProductService class. The low-level module is naturally the XMLConverter class. At this point, it is clear that the ProductService class is dependent on the XMLConverter class. Because when you decide to do data sharing in JSON format, the class you need to change will definitely be the ProductService. Yes, you will have to change the entire installation to replace the light bulb.

So how should we organize the architecture first? Here, I think you are aware that your large module’s Publish method is the main element. The Loosely Coupling approach will then combine the SRP principle and the ISP policy to incorporate the Convert method into a separate Interface.

And we must change our big module like this:

With this change, you can only get a new bulb when the bulb goes off. You can even wear fluorescent if you wish!

Well, if we want to work with this class (JSONConverter or XMLConverter) when we want ac what are we going to do? This is another article topic of Dependency Injection.

Yes my friends. Keep on reading this blog! We’ll meet you soon!

Do not forget to visit our programming memes pages! Click here!

Comments are closed.