您的位置:知识库 » 软件设计

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

作者: T2噬菌体  来源: 博客园  发布时间: 2009-04-13 09:48  阅读: 4002 次  推荐: 0   原文链接   [收藏]  
摘要:要想真正描述一个世界,仅有结构式不行的。开始我们说过,世界观主要关注两个方面:一是世界是什么样子的(结构),另一个就是世界时如何演进的(运作)。现在,我们来讨论对象论中关于世界运作的理论。
[1] 世界本没有类
[2] 程序世界
[3] 依赖是如何被倒置的
6.8、依赖是如何被倒置的

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

6.2

图6.2、没有接口的依赖

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

6.3

图6.3、引入接口后的依赖

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

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

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

6.4

图6.4、服务类拥有接口

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

6.5

图6.5、客户类拥有接口

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

      依赖倒置原则(DIP):客户类和服务类都应该依赖于抽象(接口),并且客户类拥有接口。

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

6.9、神秘的统治者

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

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

6.10、运作起来吧

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

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

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

0
0
标签:面向对象

软件设计热门文章

    软件设计最新文章

      最新新闻

        热门新闻