blocks|key|1765740|text|依赖反转的目的是为了使软件可重用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1765741|其思想是，它们依赖于一些抽象的接口，而不是相互依赖的两段代码。然后，您可以在没有其他组件的情况下重用这两个组件。|1765742|最常见的实现方式是通过控制反转(IoC)容器，比如Java中的Spring。在这个模型中，对象的属性是通过XML配置来设置的，而不是让对象去寻找它们的依赖关系。|1765743|想象一下这个伪代码。|1765744|public+class+MyClass
{
++public+Service+myService+=+ServiceLocator.service;
}|code-block|syntax|javascript|1765745|MyClass直接依赖于Service类和ServiceLocator类。如果你想在另一个应用程序中使用它，它需要这两者。现在想象一下..。|1765746|public+class+MyClass
{
++public+IService+myService;
}|1765747|现在，MyClass依赖于单个接口，即IService接口。我们让IoC容器实际设置该变量的值。|1765748|因此，现在，MyClass可以很容易地在其他项目中重用，而不会带来其他两个类的依赖。|1765749|更好的是，您不必拖动MyService的依赖关系，以及这些依赖关系的依赖关系，并且...好吧，你明白我的意思了。|1765750|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|12|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|J|7|14|8|@]|9|@]|A|$K|L]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

The point of dependency inversion is to make reusable software.

The idea is that instead of two pieces of code relying on each other, they rely on some abstracted interface. Then you can reuse either piece without the other.

The way this is most commonly achieved is through an inversion of control (IoC) container like Spring in Java. In this model, properties of objects are set up through an XML configuration instead of the objects going out and finding their dependency.

Imagine this pseudocode...

<pre><code>public class MyClass
{
 public Service myService = ServiceLocator.service;
}
</code></pre>

MyClass directly depends on both the Service class and the ServiceLocator class. It needs both of those if you want to use it in another application. Now imagine this...

<pre><code>public class MyClass
{
 public IService myService;
}
</code></pre>

Now, MyClass relies on a single interface, the IService interface. We'd let the IoC container actually set the value of that variable.

So now, MyClass can easily be reused in other projects, without bringing the dependency of those other two classes along with it.

Even better, you don't have to drag the dependencies of MyService, and the dependencies of those dependencies, and the... well, you get the idea.

blocks|key|1550834|text|这里的其他人已经给出了好的答案和好的例子。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1550835|DIP之所以重要，是因为它确保了OO原则“松散耦合设计”。|offset|length|1550836|你的软件中的对象不应该进入一个层次结构，其中一些对象是顶层对象，依赖于低级对象。低级对象中的更改将波及到您的顶层对象，这使得软件对于更改非常脆弱。|1550837|您希望您的“顶级”对象非常稳定，并且不容易发生变化，因此您需要颠倒依赖关系。|1550838|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Dependency_inversion_principle^0|0|0|3|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]]]

Good answers and good examples are already given by others here.

The reason <a href="http://en.wikipedia.org/wiki/Dependency_inversion_principle" rel="nofollow noreferrer">DIP</a> is important is because it ensures the OO-principle "loosely coupled design".

The objects in your software should NOT get into a hierarchy where some objects are the top-level ones, dependent on low-level objects. Changes in low-level objects will then ripple-through to your top-level objects which makes the software very fragile for change.

You want your 'top-level' objects to be very stable and not fragile for change, therefore you need to invert the dependencies.

blocks|key|1765880|text|基本上它是这样说的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1765881|类应该依赖于抽象(例如接口、抽象类)，而不是具体的细节(实现)。|1765882|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Basically it says:

Class should depend on abstractions (e.g interface, abstract classes), not specific details (implementations).

blocks|key|1765978|text|依赖反转原理(DIP)认为|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1765979|i)高级模块不应该依赖于低级模块。两者都应该依赖于抽象。|1765980|ii)抽象永远不应该依赖于细节。细节应该取决于抽象。|1765981|示例：|1765982|++++public+interface+ICustomer
++++{
++++++++string+GetCustomerNameById(int+id);
++++}

++++public+class+Customer+:+ICustomer
++++{
++++++++//ctor
++++++++public+Customer(){}

++++++++public+string+GetCustomerNameById(int+id)
++++++++{
++++++++++++return+"Dummy+Customer+Name";
++++++++}
++++}

++++public+class+CustomerFactory
++++{
++++++++public+static+ICustomer+GetCustomerData()
++++++++{
++++++++++++return+new+Customer();
++++++++}
++++}

++++public+class+CustomerBLL
++++{
++++++++ICustomer+_customer;
++++++++public+CustomerBLL()
++++++++{
++++++++++++_customer+=+CustomerFactory.GetCustomerData();
++++++++}

++++++++public+string+GetCustomerNameById(int+id)
++++++++{
++++++++++++return+_customer.GetCustomerNameById(id);
++++++++}
++++}

++++public+class+Program
++++{
++++++++static+void+Main()
++++++++{
++++++++++++CustomerBLL+customerBLL+=+new+CustomerBLL();
++++++++++++int+customerId+=+25;
++++++++++++string+customerName+=+customerBLL.GetCustomerNameById(customerId);


++++++++++++Console.WriteLine(customerName);
++++++++++++Console.ReadKey();
++++++++}
++++}|code-block|syntax|javascript|1765983|注意:类应该依赖于像接口或抽象类这样的抽象，而不是具体的细节(接口的实现)。|1765984|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|U|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

Dependency Inversion Principle (DIP) says that 

i) High level modules should not depend upon low-level modules. Both should depend upon abstractions.

ii) Abstractions should never depend upon details. Details should depend upon abstractions.

Example: 

<pre><code> public interface ICustomer
 {
 string GetCustomerNameById(int id);
 }

 public class Customer : ICustomer
 {
 //ctor
 public Customer(){}

 public string GetCustomerNameById(int id)
 {
 return "Dummy Customer Name";
 }
 }

 public class CustomerFactory
 {
 public static ICustomer GetCustomerData()
 {
 return new Customer();
 }
 }

 public class CustomerBLL
 {
 ICustomer _customer;
 public CustomerBLL()
 {
 _customer = CustomerFactory.GetCustomerData();
 }

 public string GetCustomerNameById(int id)
 {
 return _customer.GetCustomerNameById(id);
 }
 }

 public class Program
 {
 static void Main()
 {
 CustomerBLL customerBLL = new CustomerBLL();
 int customerId = 25;
 string customerName = customerBLL.GetCustomerNameById(customerId);


 Console.WriteLine(customerName);
 Console.ReadKey();
 }
 }
</code></pre>

Note: Class should depend on abstractions like interface or abstract classes, not specific details (implementation of interface).

blocks|key|1766124|text|依赖倒置:依赖于抽象，而不是具体。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1766125|控制反转:+Main与抽象，以及Main如何成为系统的粘合剂。|1766126|​|1766127|📷|atomic|offset|length|1766128|1766129|下面是一些关于这方面的很好的帖子：|1766130|https://coderstower.com/2019/03/26/dependency-inversion-why-you-shouldnt-avoid-it/|1766131|https://coderstower.com/2019/04/02/main-and-abstraction-the-decoupled-peers/|1766132|https://coderstower.com/2019/04/09/inversion-of-control-putting-all-together/|1766133|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/c6a5518482ce6e4970c3f19e50ea90f5.png|imageAlt|1|LINK|MUTABLE|url|2|3^0|0|0|0|0|1|0|0|0|0|0|2A|1|0|0|24|2|0|0|25|3|0^^$0|@$1|2|3|4|5|6|7|18|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|19|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1A|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1B|8|@]|9|@$I|1C|J|1D|1|1E]]|A|$]]|$1|K|3|E|5|6|7|1F|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1G|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1H|8|@]|9|@$I|1I|J|1J|1|1K]]|A|$]]|$1|P|3|Q|5|6|7|1L|8|@]|9|@$I|1M|J|1N|1|1O]]|A|$]]|$1|R|3|S|5|6|7|1P|8|@]|9|@$I|1Q|J|1R|1|1S]]|A|$]]|$1|T|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|U|$V|$5|W|X|Y|A|$Z|10|11|-4]]|12|$5|13|X|14|A|$15|O]]|16|$5|13|X|14|A|$15|Q]]|17|$5|13|X|14|A|$15|S]]]]

Dependency inversion: Depend on abstractions, not on concretions.

Inversion of control: Main vs Abstraction, and how the Main is the glue of the systems.

<img src="https://i.stack.imgur.com/qU57n.png" alt="DIP and IoC">

These are some good posts talking about this:

<a href="https://coderstower.com/2019/03/26/dependency-inversion-why-you-shouldnt-avoid-it/" rel="nofollow noreferrer">https://coderstower.com/2019/03/26/dependency-inversion-why-you-shouldnt-avoid-it/</a>

<a href="https://coderstower.com/2019/04/02/main-and-abstraction-the-decoupled-peers/" rel="nofollow noreferrer">https://coderstower.com/2019/04/02/main-and-abstraction-the-decoupled-peers/</a>

<a href="https://coderstower.com/2019/04/09/inversion-of-control-putting-all-together/" rel="nofollow noreferrer">https://coderstower.com/2019/04/09/inversion-of-control-putting-all-together/</a>

blocks|key|1766234|text|如果我们可以假设一家公司的“高级”员工因执行他们的计划而获得报酬，并且这些计划是通过许多“低级”员工的计划的汇总执行来交付的，那么我们可以说，如果以任何方式将高级员工的计划描述与任何低级员工的特定计划相结合，通常这是一个可怕的计划。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1766235|如果一位高级管理人员有一个“改善交付时间”的计划，并指示发货公司的一名员工每天早上必须喝咖啡和做伸展运动，那么该计划是高度耦合的，凝聚力很低。但是，如果计划没有提到任何特定的员工，而实际上只是简单地要求“一个能够执行工作的实体准备工作”，那么该计划是松散耦合的，并且更有凝聚力:计划不会重叠，可以很容易地替换。承包商，或机器人，可以很容易地取代员工，高层的计划保持不变。|1766236|依存性倒置原则中的“高层次”意味着“更重要”。|1766237|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

If we can take it as a given that a "high level" employee at a corporation is paid for the execution of their plans, and that these plans are delivered by the aggregate execution of many "low level" employee's plans, then we could say it is generally a terrible plan if the high level employee's plan description in any way is coupled to the specific plan of any lower level employee.

If a high level executive has a plan to "improve delivery time", and indicates that an employee in the shipping line must have coffee and do stretches each morning, then that plan is highly coupled and has low cohesion. But if the plan makes no mention of any specific employee, and in fact simply requires "an entity that can perform work is prepared to work", then the plan is loosely coupled and more cohesive: the plans do not overlap and can easily be substituted. Contractors, or robots, can easily replace the employees and the high level's plan remains unchanged.

"High level" in the dependency inversion principle means "more important".

What is the dependency inversion principle and why is it important?

What is the dependency inversion principle and why is it important?

容器

Java

什么是依赖倒置原则?为什么它很重要？

问什么是依赖倒置原则?为什么它很重要？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是依赖倒置原则?为什么它很重要？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是依赖倒置原则?为什么它很重要？
EN