真经第六章——运作 Moving

      “运动是绝对的——牛顿”

6.1、导言

      在前五章中，我们从世界观的这话题开始，逐步引出了抽象、层次、继承和耦合。这些内容，形成了对象论中关于世界的结构体系。
      然而，要想真正描述一个世界，仅有结构式不行的。开始我们说过，世界观主要关注两个方面：一是世界是什么样子的（结构），另一个就是世界时如何演进的（运作）。现在，我们来讨论对象论中关于世界运作的理论。
      这里首先要指出一点，“对象论”是关于程序世界（即将一个软件系统看成一个世界）的世界观，而非关于现实世界的，所以，将对象论应用于现实世界时，往往会有所偏颇。其实前面的某些地方已经体现出这一点，而在运作理论这里，会体现的尤其明显。但是为了直观起见，我依然会将对象论应用于现实世界去举例子，当然我会非常谨慎和小心，并且会明确指出对象论应用于现实世界的偏颇在哪里。

6.2、世界本没有类

      对象论认为：世界的演进，是而且只是各种对象通过互相调用其他对象的公开服务而完成交互。

      注意，是对象交互，而不是类交互！没错，类之间是永远不可能交互的。因为不论是现实世界还是程序世界，从来不存在具体的类。类只是抽象思维作用于对象的产物，它帮助我们理解、记忆、分析和设计。类是抽象的概念，它“客观”存在，但不是“具体”的存在。
      例如，现实世界中，我们可以找出很多个“具体的苹果”对象，但是你能找出一个东西，说它是“苹果”这个类吗？你这一辈子吃的每一个苹果，都是一个具体的苹果对象，从来没有具体的“苹果类”和你交互过。再上升一点，你一生交互过的所有东西，都是对象，而没有一个具体的类。“类”不过是你的抽象思维作用于对象形成的帮助你理解认识世界的抽象概念罢了。“类们”从不曾和你真正交互。
      程序世界中也是一样，程序运行起来，从来都是具体对象之间的交互，类只是帮助你分析设计的概念工具罢了。
      认识到上面几点对于理解对象论的世界运行理论非常重要，时刻铭记，参与真正世界运行的，只有对象，没有类！对象在世界中，类在我们心中！
      这一小节的标题是“世界本没有类”，代表两个意思：一是世界“本来”没有类，二是世界“本质”没有类。
      你可能会问，在第五章“耦合”中，不是说依赖关系是“两个类因为可能交互而产生的关系”吗？其实，确切点说，应该是“两个类所能映射到的对象因为可能交互而产生的关系”，本质上，依赖本来是对象间的依赖，只不过在抽象时被同时抽象到类里面了。

6.3、程序世界——大同的和谐世界

      虽然在对象论里，现实世界和抽象世界的基本运作机理是一样的，但程序世界和现实世界在具体运作上有很大差别。首先，我要告诉你，程序世界时多么的大同和和谐！

      程序世界与现实世界第一点区别：现实世界的依赖以对象为单位，程序世界的依赖以类为单位。

      没明白这意味着什么？
      举个例子，在现实世界中，是不是关系很重要啊。为什么？因为你认识的人多，可依赖的人就多。例如你生病了，如果你有个医生朋友，看病就方便很多；如果你要打官司，而你又恰巧认识律师朋友，是不是很爽呢；如果你想上清华大学，刚好清华大学校长是你亲戚，那一切就好办多了是吧。
      为什么会这样？究其本质，是因为现实世界中对象间的依赖是以对象为单位的，这种依赖关系不会随着泛化过程而被泛化到类里面去。例如，有一个人现在在北京航空航天大学上学，从这“一个人可”以泛化出“人”这个类，而北航可以泛化出“大学”这个类，但这个具体的人和北航的这种关系可没有被泛化到两个类中，也就是说，并不是每一个“人对象”都可以去任何一个“大学对象”去上学的。
      不过，如果是程序世界里，上面的推理是可行的，因为程序世界中对象间的依赖是以类为单位的，这种依赖关系会随着泛化过程而被泛化到类里面去。并且，只要两个类建立了依赖，那么两个类之间的所有对象都两两依赖了。换句话说，在程序世界里，只要有一个“人”和一个“大学”发生了联系，那么这种联系就被泛化到类中了，随后，所有的“人”都可以上“任何”的大学。

图6.1、两个世界中依赖的区别

      看图6.1，假设世界上只有三个人和三所大学。在现实世界中，小龙女考上了清华，不过这和其他人其他大学一点关系也没有，这种关系并没有体现在类上，看，两个类没有任何联系。但在程序世界中，小龙女考上了清华，一下子人和大学两个类就关联起来了，接着，张无忌和郭靖这两个不好好学习的学生也沾了光，和三所大学都联系起来了。（提示：其实这里和第四章讲到的OCP和LSP联系非常紧密，读者可以联系OCP和LSP两个原则自己思考一下为什么程序世界会这样。）
      你知道了吧，在程序世界里，全世界的医生随你看，律师随你用，大学随你上，美食随你吃！多么和谐大同的美好世界！

      看了上面对程序世界的描述，你是不是已经垂涎三尺了？恨不得自己变成一段代码，跑到程序世界里。不过别着急，事情也许没有你想象的那么美好。下面我们来看另一个程序世界与现实世界的区别。

6.4、程序世界——封建的专制世界

      上文描述了程序世界是多么多么美好，不过如果有一天，你真的跑到里面去了，你可就惨了。不信看下面。话说你一进程序世界，就迫不及待想在程序世界里找个漂亮的女朋友，可以吗？对不起，不成！你想吃法国大餐，对不起，不成！你想上最好的大学，对不起，不成！……搞什么！不是说程序世界什么都可以得到吗。没错，除了选择权！

      程序世界里的对象没有选择权。

      为什么会这样？因为如果对象有选择权，就没法贯彻OCP了！你要是活在程序世界里，不但给你包办婚姻，连吃饭、上学……一切的一切，你都得服从包办，对象一点点选择权也没有。至于谁给你包办的，那是后话。
      看了这些，你还敢去程序世界吗？不过这还不是最恐怖的，告诉你更恐怖的一点：

      程序世界里的对象不认识对象。

      没错，良好的面向对象提倡对象不认识对象！很不可思议？其实，这就是所谓的“低耦合”，我们喊了那么多年的“低耦合”，到底什么是低耦合？所谓低耦合，就是先剥夺对象的选择权，再剥夺对象的感觉。对象间谁也不认识谁，只知道对象能提供什么服务。
      我们现在了解了程序世界是什么样子了，下面，我们讨论程序世界为什么要这样。

6.5、有奶就是娘

      中国有句俗语，叫“有奶就是娘”，往往用来讽刺那种六亲不认，两面三刀，谁给好处就跟谁的无耻小人。不过，面向对象可是非常提倡“有奶就是娘”的行为。如果我们的程序都能做到“有奶就是娘”的地步，那就真是实现了“低耦合”这一教义了，套用梁朝伟的话，在程序世界里，有奶就是娘的行为“是美德”。

      要理解上述道理，我们要先抛却我们脑中的道德、廉耻等概念，从本质上看看“有奶就是娘”体现了什么哲学道理。
      “有奶就是娘”，纯从字面解释，是说任何一个人，只要能给奶喝，就当做自己亲娘。上升到哲学层面，是说这么一个意思：不以其他对象实体本身为交互准则，而以其他对象的行为作为交互准则，与一个对象是否进行交互纯粹是从其行为判断，而不对对象本体有任何概念。
      这种处事哲学，在现实生活中是最被人鄙夷的，但在程序世界里确是最提倡的。如果一个程序世界里，所有对象都能以“有奶就是娘”的哲学去处事，那么，这就是一个最美好运作方式。

6.6、接口横空出世

      上文说到，程序世界中提倡的运作方式是“有奶就是娘”的方式，但要真正实现这种方式，似乎还少点东西。我们回顾一下，世界本来只有对象，我们从对象中抽象出了类，这就是目前我们眼中的世界。这样，我们的交互，要么以对象为准则，要么以类为准则。
      以对象为准则，显然是不行的，因为我们说了，对象间根本互不认识。以类为准则，理论上可行，但这样有问题，就是类本身是对象“实体的抽象”，是为了更好记忆、描述和认识世界而创建的对象，归根到底，还是“实体”范畴的概念，所以在哲学上还是和“以行为作为交互准则”向左。

      认识到以上困难，就能认识到，目前我们的世界还无法实现以行为为交互准则，于是，我们需要为世界再衍生一些内容。第二章说过，世界本身只有对象，而衍生其他概念的基本方法是抽象。所以，这里我们当然要用抽象衍生一些概念出来。进一步，类是对象“实体”的抽象，而我们需要的是以行为为交互准则，很自然的，我们完全可以创建一种新概念，这种概念是行为的抽象，这种新概念，就是接口（Interface）。

      接口（Interface）：对象行为的抽象。

      这里要说明，接口和类虽然都是从对象上通过抽象衍生出的概念，但两者本质不同，是从对象的两个不同的哲学角度和动机，抽象出的不同概念，并形成世界两个完全不同的方面（Aspect）。至于两者具体有什么区别，下一小节详细讨论。

6.7、接口 vs 抽象类

      经常有朋友迷惑一件事情，抽象类和接口有什么区别？何时使用抽象类，何时使用接口？但从功能来讲，抽象类完全可以代替接口，那为什么还要有接口呢？这一小节来分析这些问题。

      这里附带说一个问题，产生这种疑惑的原因，大多是因为朋友们已经习惯了学习一个东西时，只看其什么样子？怎么用？而不习惯于弄清楚一个东西起源于哪？出现的动机是什么？其实，要想学好、用好任何一个东西，后两个问题更关键一些。
      举个例子，有人发明了吹风机，我们如果只搞清楚其是什么样子——“有个把手，有个吹风筒”，以及怎么用——“打开按钮能吹出热风，关闭按钮就停止了”。如果我们只搞清楚这些，那么我们八成用不对这个东西，为什么？因为我们根本不知道这东西是怎么来的，它为什么要被发明出来。也许我们天天拿他吹脸取暖或吹衣服，还一派洋洋得意以为用的很好的样子。殊不知这东西其实是用来吹头发帮助头发快点干起来的。
      不要笑，这种事经常发生在我们身上。因为在软件开发中，有太多的东西，我们只顾着学习其是什么样子，怎么个用法，也许就像吹风机一样，这些并不复杂，然后我们就把它用到不该用的地方，还以为自己用得很好。
      用不用得好吹风机，不在于是否熟练掌握开开关关，而在于是不是用它吹头发。同理，任何东西用得好不好，不在于是不是熟练掌握用法，而在于是不是用对了地方。而要想用对地方，就要弄清楚这个东西的“怎么出来的”和“出来是做什么用的”。

      说了挺多，我们回到接口和抽象类的话题上来。
      首先要说明一点，“抽象类（Abstract Class）”和“类（Class）”在哲学意义上没什么区别，其区别仅仅是实现层面上的，即抽象类只不过是一种特殊的类，编程环境强制不准这种类生成实例，哲学意义上两者没有任何区别。所以，从哲学层面讨论“抽象类与接口对比”和讨论“类与接口对比”是等价的。

      类与接口的不同点有以下几点：
      I. 抽象范畴不同。类是对象“体征”的抽象，接口是对象行为的抽象。
      II. 抽象动机不同。抽象出类是为了帮助记忆、认识世界，抽象出接口是为了实现低耦合交互。
      III. 关注不同。类关注共同的体征，接口关注用来交互的行为。
      IV. 存在范畴不同。类存在于抽象层次树上，接口存在于接口网。
      V. 应用范畴不同。类应用于结构范畴，是静态概念，接口应用于运作范畴，是动态概念。

      上面的条目有点学术了，通俗说来，类是从对象实体的的体征范畴上抽象出来的，用来帮助我们记忆、分析世界不同的对象，主要表明对象“什么样子”；而接口是从对象交互时需要的行为中抽象出来的，关注对象交互时需要的行为。
      还是举个例子吧。
      例如，有一群具体的司机和好多辆具体的汽车，我们可以从司机中抽象出“司机”这个类，从汽车抽象出“汽车”这个类，这种抽象是“体征范畴”的，抽象的目的仅仅是帮助记忆、认识，完全和交互没有关系。而当考虑到交互——司机需要驾驶汽车，于是抽象出一个“可驾驶”这个接口。注意，一但“可驾驶”这个接口被抽象出来，就完全和司机以及汽车没有关系了，除了汽车，拖拉机、轮船、飞机都可以实现这个接口，而不一定是司机，会开车的任何人都可以通过“可驾驶”这个接口去驾驶任何实现“可驾驶”接口的东西。这样一来，“驾驶”这种交互就完全取决于这个接口了，这就是“以行为为交互准则的意思”。

      如果明白了这一小节的内容，相信大家再也不会被“接口和类有什么区别？”、“何时使用抽象类，何时使用接口？”这样的问题迷惑了，而可以挥洒自如的在系统中正确使用接口和类。一个方法：拿不准的时候问问自己，这个抽象是体征抽象还是行为抽象？是为了记忆、分析、设计还是为了交互需要？想明白，再下手。

6.8、依赖是如何被倒置的

      弄清楚了接口，下面可以谈一个有名的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原则的、低耦合的程序世界的运作形式是这样的：首先参与运作的本质只有对象，对象不直接依赖，没有选择权，互相不知道，而只知道各个接口。客户类制定接口，对象间通过接口交互，形成运作。世界的统治者依赖注入容器决定选择哪个服务类给客户类使用。

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