OO真经——关于面向对象的哲学体系及科学体系的探讨（中）

      弄清楚了接口，下面可以谈一个有名的OO原则了：依赖倒置原则（DIP）。
      如上，我们先不说DIP是什么，而是搞清楚DIP的来龙去脉。到时，朋友们自然对DIP就有深刻理解了。我们开始！
      首先，我们要说明，依赖是有方向的，客户类依赖于服务类。什么是客户类？如果A类需要B类提供的服务，那么A类就依赖B类，反之不成立。在没有引入接口前，客户类“知道”服务类，而服务类“不知道”客户类，就像下面这个样子。

图6.2、没有接口的依赖

      我们看到，司机作为客户类，汽车作为服务类。依赖的方向是从司机到汽车，以为这里司机要使用汽车提供的“驾驶”方法操作汽车。这是我们不推荐的方式，因为不够“松耦合”。于是，我们将驾驶抽象成接口，依赖变成如下形式。

图6.3、引入接口后的依赖

      如图6.3所示，我们从这种交互关系中，抽象出了“可驾驶”这个接口。注意，此时两者谁也不依赖谁，或说谁也不知道谁了。那么为什么司机可以放心呢？因为他知道可驾驶接口的存在，他要驾驶的东西一定实现了这个接口，甭管是什么，只要实现了这个接口，我就能驾驶。其实这里才体现出接口的哲学意义。

      接口的哲学意义：对客户类的保证，对服务类的约束。

      正是接口约束了服务类必须实现什么功能，客户类才可以在不知道具体服务类的情况下“放心”进行交互，因为接口对客户类提供了一种保证。希望各位能好好体会接口的这种哲学意义，这对于对象论的良好运行体质的理解非常重要。
      可是，这样还不够，我们还有一个非常重要的问题没有讨论：谁有权利定义接口？或者说服务类和客户类谁拥有接口？当然，理论上时谁拥有都可以，但却会对世界的运作产生巨大影响。我们先看服务类拥有接口的情形。

图6.4、服务类拥有接口

      如图6.4，由于服务类拥有制定接口的权利，所以各个服务类都定义了自己的接口，一般情况下他们的接口是不相容的。如图，司机可以驾驶汽车，但由于轮船、飞机各自有自己的可驾驶接口，所以会开汽车未必会开飞机和轮船，如果要开飞机或轮船还要一个个学，现实世界中就是这样一种情况。所以，这种世界的运行其实接口几乎没有起到作用，由于服务类是“大爷”，所以它们可以指定诸多霸王条款，而客户必须忍气吞声去迁就，所以，实际的依赖方向还是从客户类到服务类。
      下面在看看客户类拥有接口会是什么样子。

图6.5、客户类拥有接口

      看上图，客户终于翻身做主人了，现在客户拥有定义接口的权利，服务类必须无条件实现，这下好了，只要会开汽车，就会开轮船和飞机，因为客户有权利定义一个统一的接口，服务类必须无条件实现！这样，三种交通工具的驾驶方法必须完全一致（虽然现实世界还没有这样），这回客户终于可以扬眉吐气，体会一把“顾客是上帝”的感觉了。
      在图6.5的情况下，司机可以有权定义接口，他不必“知道”服务类，而服务类必须“知道”客户定义了什么接口，你有没有发现，依赖的方向已经悄悄倒置过来了！变成服务类依赖客户类了（谁知道谁，谁就依赖谁）！这就是“依赖倒置”的由来。不必说，所谓依赖倒置原则就是让我们必须按图6.5的方式运行世界，而不能按图6.2，6.3，6.4的方式。下面正式定义依赖倒置原则。

      依赖倒置原则（DIP）：客户类和服务类都应该依赖于抽象（接口），并且客户类拥有接口。

      我想，看过上述来龙去脉，已经不用我再去解释这个原则了吧。

6.9、神秘的统治者

      到目前为止，我们基本已经搞清楚了对象世界的运行机制。但仍有一个疑问：我们曾经说过，程序世界里对象时没有选择权的，甚至不知道谁是谁，只知道接口，那么，谁来指定服务类呢？
      例如，上述司机可以制定接口，所以汽车、飞机、轮船等可驾驶的东西都要实现，于是司机可以按照自己制定的方式驾驶东西。但是，司机不能选择驾驶什么啊，他根本不知道自己驾驶的是什么，那么，谁制定他是驾驶飞机、汽车还是轮船呢？
      似乎冥冥中，这个世界存在一个统治者，它掌管所有对象之间谁和谁交互（只要不违反接口），否则，世界根本没法正常运行。没错，程序世界是有这么一个统治者，他就是大名鼎鼎的“依赖注入容器(DI)”，也有人叫做“控制反转容器(IoC)”。
      什么叫依赖注入？什么叫控制反转？如果你看了上面的文章，那太好理解了，依赖注入就是容器挑选符合接口的服务类为客户类提供服务。例如，上面司机要一个可驾驶的东西，容器就会根据既定规则选择一个，可能是飞机、可能是汽车、也可能是轮船，交给司机。司机驾驶就行了，不用管是什么，反正知道这东西肯定实现了“可驾驶”接口。

      让我们向这个伟大的统治者致敬吧，没有他，程序世界可真玩不转了（当然，如果某个程序世界不符合DIP甚至没接口，都是类之间依赖，那么就不需要依赖注入容器了，不过这么一来，可就是“高耦合”了，是OO所反对的）。

6.10、运作起来吧

      到了这里，根本不用我废话说程序世界时怎么运作的了，因为上面都已经说明白了。不过，我还是用短短几句话总结一下吧。

      一个符合OO原则的、低耦合的程序世界的运作形式是这样的：首先参与运作的本质只有对象，对象不直接依赖，没有选择权，互相不知道，而只知道各个接口。客户类制定接口，对象间通过接口交互，形成运作。世界的统治者依赖注入容器决定选择哪个服务类给客户类使用。

      好了，关于程序世界的运作哲理就讲到这里了，大家可以在脑子里描绘一下上述运作情景，加深印象。