Do you see how the arrow from the low-level module (Data Access) to the high-level module (Business) changes direction? And how both “Business Logic” and “SqlDatabase” point to the same abstraction? Instead of high-level code being dependent on low-level code with all its details, they are both dependent on an interface (the abstraction). Here you can see a simple UML diagram of an example with and without Dependency-Inversion. Also, we want to be able to re-use the high-level modules (for example when we want to provide a new interface like a mobile app of API) and if we’re tightly coupled to low-level modules, this becomes a lot harder. In other words, we want to minimize the blast radius of those changes. When we make a change in a low-level module, we want to prevent that we also need to make changes a high-level module. Things like the user interface, the communication with web services, persistence regularly receive more updates than business rules and policies. Why do we want to avoid high-level modules being dependent on low-level modules? In general, low-level modules tend to change more often than high-level modules. High-level means the code is dealing with policies, business rules and the bigger picture. Low-level means closer to the user or metal (think of UI, I/O, network, storage etc.) and contains the details. Details should depend upon abstractions.īefore we look into the details of this, let’s first define high-level and low-level in this context. Abstractions should not depend upon details.High-level modules should not depend on low-level modules.The Dependency-Inversion Principle consists of two rules: That’s why I searched for some examples of these issues in Open Source projects and use them in this series. The SOLID principles are often explained by using simple examples, but that sometimes makes it hard to spot them in your own code for a real project. SOLID is an acronym for the following design principles: This time, we’ll discuss the Open/Closed Principle. Last time, we looked at the Open/Closed Principle. ![]() This blog is part of a series explaining the SOLID design principles by looking at code from real projects or frameworks.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |