我看JavaScript（七）——程序构造理论与OO

理论的科学性取决于其对现象的可解释性。在前一文我们初步猜想了工程构造中构件的一些形式属性和处理原则（或许还很不成熟），现在我们开始尝试用其对【面向对象】的一些常见现象进行解释，同时对芭芭拉女士的观点的作出一些修正。

程序构造理论

我们之前说了，程序构造技术交叉了程序理论和工程构造理论，简单的理解就是用前一文总结到的构件的处理原则（1构造理论），去处理程序（2程序理论）——对程序工程进行构件分解。

根据前文总结到的构件处理原则，我们可概略如下：

• 第一，构件是成品功能半成品；
• 第二，构件具有功能复杂度；
• 第三，构件可分解来降低功能复杂度；
• 第四，构件复杂度有一个折中的度；

那程序作为一种特殊的工程成品，可以怎样的被解构呢？前一文我们大略根据常识指出程序的一些构件，但是对程序确切是什么，有怎么性质可被处理，也是在一种猜想之中，程序理论还不成熟。

不过，我们大概认识到，程序对用户来说就是「计算结果」，对开发者来说就是「计算语句」，而二者是一体两面的。如果工程成品具有某种满足人需求的功能，程序的功能就是被执行后产的计算结果；那么计算结果（注：计算代码观）可怎么被分解呢？又有怎样的复杂度性质呢？程序的认识似乎可转移到计算语句与计算结果，计算结果的复杂度可理解对应的计算语句的多寡。

计算结果与计算语句是一对一的关系，当计算结果很“高级”时，程序就是由一集很大的计算语句组成。所以分割任务似乎也是很简单直观：对计算结果进行“降级”解构，再对应分解相应的计算语句。

如此我们推得：

• 第一，程序的功能的复杂度被「纵向」分解为模块、类对象、函数等【构件种类】；
• 第二，在同种构件种类上，根据功能规模横向分割多个具体功能构件。

这似乎已经解释完成了程序构造理论或技术——程序功能、构件复杂度及分解，和构件粒度。

面向对象式程序构造

现在开始分析面向对象，看看这种特殊程序构造术增加了怎么样的具体构造方式，例如封装、继承和多态等特性的实质。

实际开发都是抽象的

在程序构造理论上，程序应该是由一大集「功能完整」的计算语句组成，根据复杂程度可分别由不同开发者开发不同的构件，再结合到一起；而我们现在看到的程序（面对别人的制作的源码），到处是各种变量、表达式等「间接的“不完整”的计算语句」，这是因为大部分都是已经经过某种工程技术处理过，这种技术就是抽象。

实际开发中的代码，都是抽象过的：参数化的函数，类使用前要先实例化等。

对工程原料抽象化

我们都知道「函数」是对一集计算语句封装，经验参数化抽象后，被很多地方调用。建筑师建造的房子是具体的实物，效果图只是指导，不是房子的一部分；然而，像抽象的表达式、函数、类常常被认为是程序成品的一部分；对工程原料进行抽象，这是程序的特点。程序的这种特点，除了本身（指令语句）有别于实物，具有一种执行上时间特性外——计算数据要到运行才能确定，主要是靠编译器（对应该的语言）的支持——对抽象过的原料进行实际恢复。

抽象的工程意义

抽象是极富意义的，意义分别工程设计和开发两个方面。建筑过程中，墙还是一堵一堵的建造，并不能像乐高积木可以预先复制好直接接合上去，开发上能复用构件是程序抽象第一大意义；第二个意义是程序设计。不同的设计师可以在独立在一个抽象边界内工作，再通过抽象接口协作。例如我定义一个类，或全局函数，你可根据功能需要（类名，及抽象化参数）派生出实例，直接使用。

面向对象交叉了抽象理论

由此我们可以推得，编程自从汇编语言开始，经面向过程、面向对象，再到面向领域等，为了开发上的便利，工程师有意无意的引用了一种可称为「抽象化」的工程技术，而，面向对象可以认为是在程序构造理论基础上，交叉了这种「抽象处理」的理论。而面向过程与面向对象的区别，在于抽象化的单元不同。