课间休息刚一结束，引号便重开话题：“OOP方兴未艾，AOP又开始崭露头角。AOP算是OOP的一种补充、一种分支还是一种超越？”

叹号故作捶胸顿足状：“OOP还没有完全吃透，又来了个什么AOP。”

“不同的人对新生事物采取不同的态度。”冒号王顾左右而言他，“追星族倾向于盲目追捧，唯恐落伍，他们信奉新潮的、流行的就是好的；守旧派倾向于本能抗拒，回避求新，他们认为经典的、传统的才是好的。”

引号和叹号互视一眼，不情愿地戴上了老冒派发的帽子。

冒号续道：“从宏观角度看，太阳底下没有新鲜事——AOP无非是SoC原理和DRY原则的一种应用；从微观角度看，太阳每天都是新的——AOP虽自OOP的土壤中长出，却脱离藩篱自成一体，并且嫁接到非OOP的领地，不仅在纯过程式语言、函数式语言、甚至逻辑式语言中得到发展，而且本身也具备了一定的声明式语言特征，成为一种新的软件模块化方式。”

问号举手：“什么是SoC和DRY？”

引号代答：“SoC就是Separation of Concerns，即关注点分离；DRY是Don’t Repeat Yourself，即尽量减少重复代码。”

“答案正确，加十分！”冒号戏赞道，“不良代码通常有两种病征：一是结构混乱，或聚至纠缠打结、或散至七零八落；二是代码重复，叠床架屋、臃肿不堪。治疗此类病症一个有效的方法是抽象与分解：从问题中抽象出一些关注点，再以此为基础进行分解。分解后的子问题主题鲜明且独立完备，既不会牵一发而动全身，也不会四分五裂、支离破碎。同时具有相同特征的部分可以象代数中的公因子一样提取出来，提高了重用性，减少了重复性。”

句号醒悟道：“这不就是模块化吗？”

“准确地说，抽象是前提，分解是方式，模块化是结果。”冒号很讲究精确，“大家记得庖丁解牛的故事吧？在常人眼中复杂的牛体，庖丁经过抽象，已目无全牛，及至提刀分解，自是游刃有余。待牛如土委地，模块化即成。”

句号举一反三：“前面提到的编程范式的基本思想大多不也如此？将程序分别抽象分解为过程、函数、断言、对象和进程，就依次成为过程式、函数式、逻辑式、对象式和并发式。至于泛型式——”

句号讲不下去了。

“泛型式虽未引入新类型的模块，其核心也是抽象出算法后与数据分解。”冒号为其解围，“以此类推，切面式的AOP将程序抽象分解为切面。”

问号提问：“抽象与分解的原则是什么？”

冒号作了个V字：“两条：单一化，正交化。每个模块职责明确专一，模块之间相互独立，即高内聚低耦合（high cohesion & low coupling）^[1]。此原则相当普适，是分析复杂事物的一种基本方法，在数学和物理中应用得尤为广泛，如质因式分解、正交分解、谱分解等等。”

逗号调皮地抬杠：“为什么称为正交化呢？斜交化不行吗？”

冒号呵呵一笑：“在数学中互为正交的两个向量在彼此方向上投影为零，意味着彼此独立、互不影响，斜交可不行。”

逗号吐了吐舌头。

“诚如前述，AOP以切面为模块。”冒号返回主题，“切面Aspect常直译为‘方面’，但它描述的是横切关注点（cross-cutting concerns），故‘切面’更准确生动，而‘方面’则失之空泛呆板。何谓横切关注点？顾名思义，乃是与程序的纵向主流执行方向横向正交的关注焦点。不妨回顾一下，无论是过程式的函数，还是对象式的方法，都包含了完整的执行代码。但有些代码横跨多个模块，以片断的形式散落在各处，虽具有相似的逻辑，却无法用传统的方式提炼成模块，难以实现SoC与DRY。典型的例子如：在调用某些对象的方法、读写某些对象的域、抛出某些异常等等前后，需要用到统一的业务逻辑，诸如日志输出、代码跟踪、性能监控、异常处理、安全检查、事务管理等等。为解决此类问题，AOP应运而生。它将每类横切关注点封装到单独的Aspect模块中，将程序中的一些执行点与相应的代码绑定起来。单个的执行点称为接入点（join point），例如：调用某个对象的方法前后；符合预先指定条件的接入点集合称为切入点（pointcut），例如：所有以set为命名开头的方法；每段绑定的代码称为一个建议（advice）。”

问号有点疑问：“接入点与切入点有何区别？”

冒号释疑：“望文生义，接入处是点，切入处是面，面由点组成。advice定义于切入点上，执行于接入点处。换言之，共享一段附加代码的接入点组成了一个切入点。切入点一般用条件表达式来描述，不仅有广泛性，还有预见性——以后新增的代码如果含有满足切入点条件的接入点，advice中的代码便自动附着其上。这是AOP的威力所在，但有时也是麻烦所在。”

引号很较真：“好像一些书上把join point译作连接点，把advice译作通知。”

“误导，完全是误导！”冒号有些痛心疾首，“何谓join point？是advice中额外代码接入之处，join显为‘参加’、‘加入’之意。如果说翻作‘连接’ 只是因缺乏动感和方向性而不够贴切的话，将advice译作‘通知’则近乎荒谬了。advice是在原有程序流程中加入的额外流程，可理解为建议采取的措施，而‘通知’强调的是一种信息，难道是程序运行到join point的信息？抑或采取某种行动的信息？简直不知所云。”

顿了一会，冒号仍意犹未尽：“英文好的技术不好，技术好的英文不好，两者都好的不屑去翻译，导致市面上的译书虽汗牛充栋，然佳作寥寥。这里奉劝各位，如果真想成为优秀的程序员，一定要尽可能地读原文的书籍、文章和文档。事实上，凡是科学和艺术方面的专业人员，要想专业水平上一层台阶，都应读该专业权威经典的原文。要知道，语言之间的天堑原本难以弥合，译者的专业水准、语言功底和严谨程度更是参差不齐。纵使万事俱备，一年半载后的译书便如隔夜的饭菜，虽刚出炉，已然不新鲜了。”

逗号抱怨：“英文虽读得懂，但太慢、太费劲了。”

“多读，读多了就习惯了。”冒号鼓励着，“对程序员来说，英语也是一门计算机语言，而且是必修的语言。”

课堂上有这么一个规律，越是题外的话大家讨论得越欢。下面果然开始嘈杂起来，冒号也乐得乘机歇歇嘴。

等大伙渐渐把视线重新聚焦到讲台上，冒号才继续讲课：“从软件重用的角度看，可以这么理解AOP与OOP的关系：OOP只能沿着继承树的纵向方向重用，而AOP则弥补了OOP的不足，可以在横向方向重用。这算是回答了引号开始提出的问题：AOP不是OOP的分支，也不能说是超越了OOP，而是OOP的一种补充——尽管AOP并不局限用于OOP语言。”

问号的求知欲很强：“AOP实现的机理是什么？”

冒号回答：“如果一个程序是一个管道系统，AOP就是在管道上钻一些孔，在每个孔中注入新的代码流。因此AOP实现的关键是将advice的代码嵌入到主体程序之中，术语称编织（weaving）。这是很自然的——将问题分解之后再合成，问题才得以还原。编织可分两种：一种是静态编织，通过修改源码或字节码（bytecode）在编译期（compile-time）、后编译期（post-compile）或加载期（load-time）嵌入代码——请注意，这里涉及到刚才提到的元编程和产生式编程；另一种是动态编织，通过代理（proxy）等技术在运行期（run-time）实现嵌入。具体的工具包括一些扩展性语言如AspectJ、AspectC++、Aspect#等和一些框架如AspectWerkz、Spring、Jboss AOP等。”

叹号搔着头：“听起来怪复杂的。”

引号倒不在乎：“这些机理是AOP的实现者需要操心的，使用者只需关心AOP是否好用，性能如何等等。”

“为了让你们有更直观的印象，我们借用光学原理来类比。”冒号用幻灯片展示了一幅图——

图3-3. 切面式编程

“众所周知，白光经过三棱镜的折射而分解为七色光，是谓光的色散。再经过一个倒置的三棱镜，七色光又重新会聚为白光。”冒号简述中学的物理知识，“如果把一个复杂的系统看作复合色的白光，经过第一个三棱镜——关注分离器，系统被分解为不同的切面，如同不同的单色的彩光。这些切面经过第二个三棱镜——编织器，再度合成为原系统。”

叹号脸上的迷惘之色渐去：“这下清楚多了。”

句号积极发言：“从中看出，AOP的实施分三步：切面分解、切面实现和切面合成。其中第一步是在设计者的头脑中进行的，第三步是通过AOP的工具实现的，真正需要程序员编码的部分在第二步，即分别实现各切面的advice。”

冒号赶紧补漏：“你好像忽略了切面的另一要素pointcut，如果程序员不指明advice挂靠的切入点，系统如何知道该何时何处调用他编写的执行代码呢？”

句号的嘴张成O状：“是哦，我怎么把这茬给忘了？”

在AOP的议题结束前，冒号不忘指出：“与OOP一样，AOP在带来便利的同时，也增加了一定的复杂度和性能损耗。它们更适用于大中型程序，用在小型程序中则不啻牛刀杀鸡。”

短憩之后，引号迫不及待地问：“面向对象的范式应该是一种特殊的命令式吧？”

“面向对象？”冒号咕哝着，“姑且称之为OO或对象式吧，既不标新立异，也不以讹传讹。在回答你的问题之前，请先回答我的：什么是OOP？”

引号应答如流：“OOP（Object-Oriented programming）是一种计算机编程模式，它以对象作为问题空间的基本元素，利用对象和对象间的相互作用来设计程序。所谓对象，是实际问题中实体的抽象，具有一定的属性和功能。OOP的三个基本特征是：封装性、继承性和多态性。所谓封装性就是——”

冒号作了个暂停的手势：“OOP的的基本特征相信大家早就耳熟能详了，那么根据你刚才的定义，能否得出OOP一定是命令式的结论？”

引号歪头想了一阵，答道：“从定义上好像并不能得出，难道C++、Java、C#不是命令式的吗？”

冒号回答：“当然是，但这不妨碍Clos成为OO版的Lisp，而Prolog也有不少融入OO特征的扩充，如Visual Prolog、Logtalk等。OOP虽然是在命令式的基础上发展起来的，但其核心思想可泛化为：以数据为中心组织逻辑，将系统视为相互作用的对象集合，并利用继承与多态来增强可维护性、可扩展性和可重用性。这种思想也能应用到函数式和逻辑式中，只不过对象的方法从命令式中的过程分别换成函数式中的函数和逻辑式中的断言罢了。大致说来，命令式、函数式和逻辑式互相平行，而OOP与它们正交。”

问号提问：“OOP已经成为一种潮流，上堂课列举的十二种流行语言中只有C不是OO的，这是否意味着OOP将要一统天下？”

“严格说来，VB（VB.NET除外）和JavaScript也不是OO的，只是基于对象的（Object Based）^[1]。” 冒号纠正道，“至于OOP是否会一统天下，答案是否定的。首先，与能独当一面的三类最基本的范式不同，纯粹的OOP是不存在的^[2]，必须结合其他范式；其次，世上没有包治百病的万灵丹方，OOP也不例外。用软件业的行话来说：没有银弹（No silver bullet）^[3]。OOP最适用于大型复杂的、交互式的、尤其是与现实世界密切相关的系统，但在小型应用、数学计算、符号处理等方面并无优势。需要指出的是，语言和范式的流行，与大公司支持和商业推动是密切相关的。有人说OOP其实是MOP（Money-Oriented Programming），即以金钱为导向的。虽有过激之嫌，但有经验的股民都知道，有主力运作的股票总是涨得快一些的。当然OOP能流行，自有独到之处，谁能说说它到底好在哪里？”

逗号抢答：“OOP能提高软件的可维护性、可扩展性和可重用性。”

冒号反问：“为什么过程式编程的可维护性、可扩展性和可重用性就差呢？”

感到来者不善，逗号有点发虚：“因为OOP具有信息隐藏、继承和多态的特征。”

冒号并不买帐：“首先，将可维护性、可扩展性和可重用性与OOP划等号，是只见树木，不见森林——那是所有范式和语言的共同目标。其次，以C语言为例，信息隐藏可用关键字static来实现；继承可用合成（composition）来代替；多态可以利用函数指针来实现。更何况这些只是手段而非目的，只要设计合理，C程序同样具有可维护性、可扩展性和可重用性，性能效率还更优越。即使在OOP日益风行的今天，C的占有率始终稳踞前列，许多大型复杂软件如操作系统、数据库等仍以C为主，这足以证明其仍堪大用。”

见逗号有些理屈词穷，冒号语气放缓：“请不要误解，我并非OOP的反对者，相反今后还要重点讨论它。但我希望大家少一点照本宣科和人云亦云，多一点独立思考，甚至不妨标新立异。”

稍作停顿，冒号继续发问：“过程式编程与OOP在设计理念上有什么区别？”

“过程式编程的理念是以过程为中心，自顶向下、逐步求精^[4]。”引号一出口就自感有些“照本宣科”，见冒号正用鼓励的目光看着他，这才继续说下去，“OOP则正相反，以数据为中心，自底向上、逐步合并。”

冒号首肯道：“如果把整个流程看作一颗倒长的大树，过程式编程自树根向下，逐渐分支，直到每片树叶，类似数学证明中的分析法，即执果索因的逆推法；OOP则从每片树叶开始，逐渐合并，直到树根，类似数学证明中的综合法，即执因索果的正推法。”

句号心领神会：“倘若把树根看成主函数，离树根越近，离用户需求也越近。如果用过程式编程，由于是逆推法，树干改变容易导致树枝相应改变，因此一旦用户需求发生变化，可能会从树根波及到树枝甚至树叶，维护起来殊为不易。相反OOP从树叶开始设计，离用户需求较远，抽象程度较高，受波及的程度较小，因此更易维护和重用。”

冒号拊掌赞道：“好极了！”

问号不解：“您刚才不还说C程序同样具有可重用性吗？”

冒号微微一笑：“数学中分析法与综合法往往是结合起来使用的，过程式编程与OOP也是如此，只不过各有偏重罢了。句号的一番话虽不无道理，但也授OOP的反对者以口实：OOP鼓吹的可重用性来自‘自底向上’的设计模式，而这种模式并非OOP的专利。其实软件设计的最重要的并不是编程语言，甚至也不是编程范式，而是抽象思维。关于这一点，我们今后还会详细阐述。”

叹号不甘寂寞，插言道：“OOP以对象为基本模块单位，而对象是现实中具体事物和抽象概念的模拟，这使得编程设计更自然更人性化。”

“深合吾意！”冒号挥动着右手，“尽管OOP最大的卖点是其高度的可重用性，相比其他范式却并不具明显优势。但它更接近人类的认知模式，编程者更容易也更乐于用这种方式编程，这是它深入人心的一个重要原因。比较一下两种用法：牛.吃（草）与吃（牛，草），哪种更接近人类思维？”

有人在底下嘀咕：“如果把牛换成狗，那么一个是狗吃屎，一个是吃狗屎。”

全班捧腹。

冒号也忍不住笑了：“OOP人性化的另一表现是其接口简洁易记。看看Win32 API、Unix API等之类操作系统接口或OCI之类的数据库接口，函数的参数动辄七八个乃至上十个，函数名和数据结构成员也多冗长晦涩，既难记又易错。相比之下，相应的Java的API显然平易近人得多。”

问号刨根问底：“为什么C的API不能象Java的那么简洁呢？”

冒号释疑：“单纯这么比较其实对C并不公平，因为Java的API虽然简洁易用，但功能上与相应C的API并不等同，换句话说，Java把接口粗粒度化了。”

“接口粗粒度化？”引号质疑道，“就是把一些函数包装起来吧？我们也可以用C将操作系统、数据库之类的API再包装一下。”

“事实上许多软件公司都曾这样做过。”冒号颔首作答，“但C函数不像Java对象，本身没有状态，只有依靠参数传递或外部变量来维持相关函数之间的联系，包装后的接口肯定不如Java简洁，但应该比Java高效。说白了，OOP就是将相关的函数用数据粘合，重新包装后再贴上对象的标签。从这种角度上看，与其说OOP更具重用性，不如说更具易用性。”

叹号狐疑道：“OOP并不更具重用性？这可是它的金字招牌啊！”

冒号冷哼一声：“不要被金字招牌晃晕了眼，我来问你：是收音机、电视机之类的电器产品更具重用性呢，还是电阻、电容之类的电器元件更具重用性？”

“当然是电器元件啦。”叹号冲口而出。

冒号因势利导：“每个电器元件具备单一的功能，正如过程式中的函数；每个电器产品是对多个相互关联的电器元件的封装，正如OOP中的对象。同样的电器元件可用于不同的电器产品，具有高度的可重用性，而电器产品重用性低，但易用性高。^[5]”

众人犹自将信将疑。

“对一个没有独立思考习惯的人来讲，与其说他认同一个理论，倒不如说他认同该理论倡导者的权威。而在他仰视权威的同时，也把自己的思想交托给了权威。”冒号颇具犬儒之风，“你们可以怀疑我的观点，但绝不可放弃自己的思考。请注意，这就是我在第一堂课提到的精神——批判精神。”

冒号这时停了下来，与在座的每位逐一对视。他仿佛想通过目光把这种精神注入到每个人的身上，就像武侠小说中通过手掌将内功传输给他人一样。并不是每个人都能理解冒号的用心，但都或多或少地感受到一种异样的气氛。

“关于OOP今天就谈到这里。”冒号恢复了常态，“请不要奇怪为何如此流行的编程范式我却一带而过，那是因为你们对它相对比较熟悉，而我们这一轮只是在作热身运动，以后再作专项训练。在结束之前，我们引进一个新视点：过程式编程的模块以函数为单位，OOP的模块以对象为单位，二者的区别是：函数是被动的实体，对象是主动的实体。过程式程序的世界是君主制的，主函数是国王，其他函数是臣民，等级分明，所有臣民在听命于上级的同时也对下级发号施令，最终为国王服务；OO程序的世界是民主制的，所有对象都是独立而平等的公民，有权利保护自己的财产和隐私并向他人寻求服务，同时有义务为他人提供承诺的服务，公民之间通过信息交流来协作完成各种任务。更进一步地，封装使得公民拥有个体身份，需要对自己负责；继承使得公民拥有家庭身份，需要对家庭负责；多态使得公民拥有社会身份，需要对社会负责。欲知个中玄机，且听我日后慢慢道来。”

众人顿觉耳目为之一新。