基于依赖反演原理的实用编程

Question

依赖反转原则在实践中所指的是，在一个系统中，高级别组件应该依赖于底层组件的抽象(而不是直接依赖于底层组件)，而底层组件应该根据这些抽象来定义。

我问题的关键点是，低级组件是用抽象来定义的，抽象是用高级组件来定义的。意思:高级组件“定义抽象”是为了方便它们，而底层组件必须根据抽象定义(通常是一个接口)。

因此，如果高级组件是Car，而底层组件是Engine，并且定义了接口IEngine --它将根据Car的需要定义，Engine必须满足这些需求。因此，如果Car能够简单地启动引擎是方便的，那么IEngine将提供一个方法start()，Engine必须实现它。

我的问题是：

在根据依赖反转原理设计的项目上开始编程时，高层组件通常是在低级组件之前实现的，即。“自上而下”的发展？

由于该原理意味着低层组件的设计是根据高层次组件的方便性而设计的，因此，首先开始对高级组件进行编程，然后根据我们在编程时所了解到的高级组件所需的内容，定义ILowLevelComponent接口是有意义的。

例如，我们正在实现一个模拟汽车的系统。Car是高级组件，而Engine和SteeringWheel是底层组件。Engine和SteeringWheel负责移动汽车的具体工作，而Car负责协调一切并创建一个功能良好的系统。

如果我们是按照DIP来设计系统，这意味着Engine和SteeringWheel是用抽象定义的，而抽象是根据Car的方便定义的。

因此，首先实现Car是有意义的，准确地理解它将如何在高级术语中工作以及它需要什么工作，然后根据Car的需要定义IEngine和ISteeringWheel接口。当然，还可以实现实现接口的具体类。

所以我要问的是:当我从事一个本着DIP精神设计的项目时，“自上而下开发”的方法是否很常见？这就是按照依赖反转原则在项目上通常所做的工作吗？

Answer 1

它通常不是用石头写的：

• 有时也可以这样做。高级组件需要一些东西，然后设计接口，然后由一个模型对象来实现它，这样就不需要等待更高级别组件的开发了。
• 有时，发展可以两种方式进行，并在中间相遇。
• 接口并不总是由高级组件“需要”来定义的，例如，即使高级组件似乎需要接口，LightSource接口也不会有getPriceInDollars方法。也许另一个接口会有getprice方法，一些实现者将实现这两个接口。
• 有时，在新项目中重用现有组件和接口。
• 有时，现有的类，从以前的项目，我可以实现新的接口，以符合新的架构，而不改变行为或打破以前的契约，也许通过使用结构设计模式(适配器，复合，装饰，等等)。
• 有时，高级组件只是简单地适应底层组件所具有的任何接口(抽象类或接口)，比如当您使用第三方库时。库的设计者(比如创建图表的库)想到了一个非常通用的消费者。这并不意味着这样的图书馆就不那么有用了。注意:它仍然是DIP，因为您正在编写抽象程序，即使第三方设计了抽象。
• 在面向对象设计( OOD )和面向对象编程( OOP )中，高级组件并不总是先写的，低级组件也不总是最后写的。DIP有一个额外的优势，那就是你不必严格地以自上而下或自下而上的方式发展。
• 较低级别的组件倾向于合并成横贯项目的API或库。