How can you apply the dependency inversion principle for more flexible software designs?

由人工智能和领英社区提供技术支持

One of the most important software design principles is the dependency inversion principle (DIP). It states that high-level modules should not depend on low-level modules, but both should depend on abstractions. This way, you can avoid tight coupling and make your software more flexible, testable, and maintainable. In this article, you will learn how to apply the DIP in your software engineering projects.

此文章中的业界达人

由社区从 5 条内容中精选。了解更多

Tim Newsom

Engineer/Entrepreneur/CTO

1 What is tight coupling?

Tight coupling means that a change in one module affects many other modules, making your software hard to modify and reuse. For example, if you have a high-level module that handles business logic and a low-level module that handles database access, and they are directly dependent on each other, you have tight coupling. If you want to change the database or the business logic, you have to change both modules.

添加您的观点

Tim Newsom

Engineer/Entrepreneur/CTO
举报内容
This is a great description. By itself it paints a picture of coupling. I think this paragraph gets the impact wrong however. Small changes might fly under the radar without much notice, its when you try to evolve software with bigger changes that this becomes an issue. Changes can ripple through the code and the tighter the coupling the more likely it is to happen.

已翻译

赞

2 How does DIP reduce tight coupling?

DIP reduces tight coupling by introducing abstractions between the high-level and low-level modules. Abstractions are interfaces or abstract classes that define the contracts or behaviors that the modules need to follow. For example, instead of having the high-level module depend on the low-level module, you can have both depend on an abstraction, such as a repository interface that defines the operations for accessing the database. This way, you can change the database or the business logic without affecting the other module, as long as you follow the abstraction.

添加您的观点

Tim Newsom

Engineer/Entrepreneur/CTO
举报内容
The common abstraction provides a means of communicating between concrete instances without needing to know what type is actually on the other side. Now, you can change one or both sides of that connection by implementing additional types that inherit from the same abstraction and plugging them into the code. The code can evolve and the impact of the change can be as localized or widespread as needed, affecting more than one location in the code with less effort. This, of course, goes hand-in-hand with dependency injection which is required to make this work properly.

已翻译

赞

3 How to apply DIP in practice?

To apply DIP in practice, you need to follow two steps: 1) define the abstractions that your modules need, and 2) invert the dependencies so that the high-level modules depend on the abstractions, not on the low-level modules. For example, if you have a high-level module that handles user authentication and a low-level module that handles email sending, you can define an abstraction, such as an email service interface that defines the methods for sending emails. Then, you can invert the dependency so that the user authentication module depends on the email service interface, not on the email sending module.

添加您的观点

Tim Newsom

Engineer/Entrepreneur/CTO
举报内容
This paragraph is touching on another principle of SOLID, the Interface Segregation principle. When you define the abstractions that your module needs, you apply the IS principle to make sure they do what they need and not something extra. Kinda like Single Responsibility, but applied to the abstractions. Then you just make your concrete types implement and use those abstractions instead of other concrete types.

已翻译

赞
Veeresh Kumar

Software Engineer
举报内容
Use a framework that in application development. For example java applications can make use of Spring Framework. This is essentially programming to interfaces coupled with Inversion of Control

已翻译

赞

4 How to implement the abstractions?

There are different ways to implement the abstractions that your modules depend on. One of the most common ways is to use dependency injection (DI). DI is a technique that allows you to inject or pass the concrete implementations of the abstractions to the modules that need them, usually through constructors, methods, or properties. For example, if you have a user authentication module that depends on an email service interface, you can inject the concrete email sending module that implements the interface to the user authentication module through its constructor.

添加您的观点

5 How to choose the abstractions?

Choosing the right abstractions is crucial for applying the DIP effectively. You should follow some guidelines, such as: 1) make the abstractions stable and coherent, meaning that they should not change frequently and they should represent a single responsibility or concept; 2) make the abstractions generic and reusable, meaning that they should not be specific to a particular implementation or use case; and 3) make the abstractions meaningful and expressive, meaning that they should convey the intention and functionality of the modules that depend on them.

添加您的观点

6 What are the benefits of DIP?

DIP has many benefits for your software engineering projects, such as: 1) it increases the flexibility and adaptability of your software, as you can easily swap or change the low-level modules without affecting the high-level modules; 2) it improves the testability and maintainability of your software, as you can isolate and mock the low-level modules and test the high-level modules independently; and 3) it promotes the modularity and reusability of your software, as you can compose and reuse the modules based on the abstractions.

添加您的观点

7 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?

添加您的观点

Tim Newsom

Engineer/Entrepreneur/CTO
举报内容
Most people don't take it far enough. They will implement an interface (abstraction) that returns concrete types instead of limiting it to abstract and primitive types. This then becomes a limitation with trying to continue following DIP. Eventually they get tied down and can't evolve anymore. I recommend the consideration of 2 "trees" in your code. One is all abstract. Every interface needed and they only return interfaces or abstract types and primitives. The other is the concrete types (services, controllers, etc). This concrete implementation will implement the interfaces and use the interfaces (abstracts) and primitives, and never another concrete type. This is the only way to really get DIP to work.

已翻译

赞

Software Engineering

+ 关注

给文章评分

我们借助人工智能创建了此文章。您认为这篇文章怎么样？

很棒不太好

举报此文章

查看全部

How can you apply the dependency inversion principle for more flexible software designs?

1

2

3

4

5

6

7

1 What is tight coupling?

2 How does DIP reduce tight coupling?

3 How to apply DIP in practice?

4 How to implement the abstractions?

5 How to choose the abstractions?

6 What are the benefits of DIP?

7 Here’s what else to consider

Software Engineering

给文章评分

感谢您的反馈

更多Software Engineering相关文章

更多相关阅读内容