资源组件的三种上下级关系

应用软件观念的变革

面向资源的应用软件开发方法虽然是在面向对象的软件开发方法上拓展出来的一个新方法，但迅速理解和掌握面向资源的应用软件开发方法精要，则不必从软件内部的体系结构的变革开始来理解，而只要从我们对应用软件的外部观念进行如下拓展开始：

传统的应用软件的观念，是将应用软件视作辅助业务工作的工具来对待。随着软件的运行环境不断在应用领域、应用地域、应用深度、应用功能和相互连接等各方面的迅速成长，软件的世界和人类社会的现实世界已经接近全面的融合了。也就是说，我们看待应用软件观念，已经可以从“是在外部辅助我们工作和生活的工具系统”发展到“就是我们工作和生活的世界本身内部的一部分”了。

完成了这一观念的变革，就能理解为什么应用软件的开发方法是面向资源的了。资源，作为推动世界运转所需的一切实体和虚体形式的材料，是一个广为人知，耳熟能详的概念。从生产生活上的物资、材料、设备、机械、人工、智力、知识、经验、信息以及他们之间的各种连接和关联的关系，甚至所需的场地、空间、资金、能量和时间及其约束关联关系，都可以被统一理解为是“资源”。所以，资源是构成人类社会的构建和运转要素的最抽象而又最通俗的概念之一。而当今的软件世界已经和现实世界高度的融合了，我们看待现实世界的构建和运转要素的方法，自然也将适应于用来看待软件世界的构建和运转的要素。

这一观念，在笔者研究和开发面向资源的应用软件开发平台“诚开智能软件平台”的实践中，一直是作为一条最基本的信条被秉承着。在此信条的指引下，寻找面向对象的软件开发中的概念和现实生活世界中的概念的对照关系，就成了一项别开生面的有趣工作。

资源组件概念由来

软件的“组件”，在现实世界的一个隐喻就是“积木”，就是软件构建和运转的主要的一种“资源”。可以说，现代的应用软件，就是通过建立和连接数量众多，功能各异的组件资源来实现系统的构建和运转的，所以，如何设计组件的构建、连接和运转的机制，就是研究面向资源应用软件开发方法的重点内容。

面向资源的应用软件开发，必定不会是以程序代码为主的方式来构建和连接软件的组件，否则，就不应该另外取名叫“面向资源”了，因为以程序代码为主的资源方式，就是传统的面向对象的软件开发方式。 虽然资源组件的构建方式是一个说来话长的问题，但对三种有趣的资源组件的上下级关系，则可长话短说。

这三种资源组件关系就是：母子关系，父子关系和主从关系。

这是现实世界人力资源的三种基本的人际上下级关系，可用来直接映射表达三种基本的软件资源组件关系。这里说是“映射”，不仅仅是一种“隐喻”，而且表示在语义关系上存在有趣的高度一致的对应关系。有趣到我在诚开智能软件平台开发的程序设计中，发现对其中两个关系的表达用词多次更改，最后还是发现直接就用原词反倒是最恰当的表达。

程序语言组件间的三类上下级关系

传统面向对象的程序代码中实现了两种最基本的组件上下级关系，是“继承关系”和“聚集关系”。

其中的“继承关系”语义非常清晰。在程序设计语言中，实现这个关系的关键词是“Class”。就是“具体类自动拥有被继承的祖先类的属性和方法定义”的关系。其表达的是后代同态于祖先的基因遗传的关系。在这层关系下，具体类继承抽象类，类实例化为对象。表现为：“祖先变，后代随变”，“模子变，实例随变”的关系。

另一类“聚集关系”的语义并不那么清晰，实际主要包含两类：一类是“聚合”，是“强聚集”，另一类是“弱聚集”，在程序语言中常用“Owner”和“Parent”来标识这两类聚集关系，即“所有者”和“父母”关系。

其中的“所有者”关系表示：聚集在“所有者”组件名下的所有组件，是以所有者为生存依赖的，即：所有者生，聚集者随生，所有者灭，聚集者同灭；

“父母”关系表示：多个“聚集者”组件是在同一个“父母”组件的承载和管理下进行活动的。对于聚集者组件而言，“父母”组件就像是容器，聚集者组件可以根据需要，更换到不同的容器之中接受管理。

经验不足的程序员经常会混淆Owner和Parent的用途。多少和这两个词汇实际含义和在这里的用法表达的含义不十分吻合有关。为什么会出现用词表达不准确，多少可能和编程语言的设计者没有把应用软件的世界看成是现实世界的一部分有关。

对资源组件间的Mother关系

在面向资源的开发方法中，软件的设计平台和应用运行平台是同一个平台。就像餐馆为了适应顾客对食材的种类多，数量少的灵活需求，把厨房的烹饪平台和顾客的饮食桌面合并为一个平台，从而发明出“火锅”一样。软件开发相当于烹饪菜肴，而软件应用则相当于消费饮食。可见，原本分管设计和应用的两个平台的合并，是实现随需应变的前提之一。

而对这一餐饮业火锅的隐喻，还可继续深入对照下去：传统面向对象编程语言的开发相当于餐馆的菜谱开发，Class就是炒菜的菜谱，Object就是炒出来的菜。按什么菜谱操作，炒出来的就是什么菜。食客只能按菜谱的目录单来点菜，厨师也只按点到的菜单的菜谱来炒菜，多菜谱混搭的饮食需求是不受欢迎的。

面向资源的应用软件开发正是要克服这种“一次性设计”带来的问题，但又不能丢失“类-实例化”机制带来的“知识重用”的效果。似乎出现了矛盾：既要得到抽象描述的知识重用的效果，又不能接受必须把抽象描述转换为实例才能运行的“鸿沟”。如何解决这个矛盾？

解决这个矛盾的诀窍，正好是中国古代哲学和西方哲学的差异的现世反映：形证法和例证法的差异性和等效性。在面向资源的开发平台中，设计元素不再是抽象的形式化的符号表述，而是实际的软件对象。比如，对需要一个整型变量的设计，不再是用编程语言的“Integer”这个词来告诉计算机，这里需要一个整型变量，而是直接在计算机中，创建一个实际的整数变量的实例来进行设计。这个实际的变量，就是计算机中实际运行着的软件资源，面向资源的开发，就是用本身就在运行着的软件资源来告诉计算机如何工作。

为解决知识性的重用问题，只需把已构建的任何组合形式的资源组件实例，当作一个样板，照此克隆或以此为模板创建新资源组件实例即可，这两类创建关系之前被称为“例型”和“类型”两类关系。其中的类型关系，在样板组件和以样板为模板创建的新组件之间，就建立了一种具有抽象约束力的表达。这种关系不仅完全可实现面向对象编程语言中的类继承和实例化的关系，而且和例型关系的交替组合，能带来广阔的动态演进机制的设计空间。

由于这类关系是决定新资源组件的产生的，因而被称为“母子关系”。在其中的资源组件的类型关系中，子总是类母的，母变子随变。在资源组件的这类母子关系中特殊的是：　即便是已经出生的子资源组件，和生其的母资源组件之间的母子关系总是存在的，只要母变化结构，子的结构也随之变化。在我的编写的诚开智能软件平台的源程序中，最后选来表达这类关系的程序用词，就是“Mother”。即：一个资源组件可以有一个Mother为母组件作为其类型，并可以同时成为其他多个资源组件的Mother。

资源组件间的Father关系

如果说母亲对子女的主要责任是“生”，那么，父亲对子女的主要责任就是“养”。“生”决定了子的性状随母，而“养”则决定子的存活状态随父。所以，对传统程序代码中实现的组件之间的“Owner”关系，在资源组件之间，则更准确地用“Father”来替代了。

显然，一个资源组件只能有一个父资源组件，整个系统是最大的父。而一个资源组件可以作为多个子资源组件的父资源组件而存在。父必定比子先生，父死子亡，否在则父死前必托孤给新的养父，这些关系在资源组件的生命周期控制中，都是可用的机制。

在软件世界中，反映现实世界的这种父子关系模型的实例比比皆是。比如，在一个智能试验工作管理系统中，所有的业务对象的数据表述集合都可认为是资源组件，而资源组件的父子关系，往往构成应用系统的主心骨，如：

一个公司和公司所设的每个部门，一个部门和部门所设的每个岗位；一个购销合同的文本和该合同所订购的产品的描述；一个产品的描述和针对这个产品所做的每项试验的试验记录；一个产品的描述和针对这个产品的每个试验报告；一项试验类型的规则和根据这个规则进行的每次试验的数据记录等等。这些都可以建模为资源组件的父子关系。

可见，父子关系是“子依托父的存在而存在”的一种特殊的一对多的组件关系。如，撤销了一个部门，那么，该部门的岗位就不复存在了。而正是这些具有父子关系的组件集合，构成了一个试验工作管理系统的数据骨架。

资源组件间的Master关系

从以上的分析可见，在传统的面向对象编程语言中（后简称OO）的组件关系Class,对应到了面向资源开发（后简称RO）的组件关系Mather;而OO中的Owner则对应到RO组件关系Father。反倒是本来该表达Master含义的时候，在OO中使用了本该表达Mother和Father含义的Parent。OO中组件关系用词的通俗语义，看来是正好搞反了。

所以，资源组件剩下的一种一对多关系就是主从关系，也就是Master关系。这和现实世界的每个人的人脉关系，真的是形成了工整而有趣的对照：每个人都是“母生父养头儿罩”着的，不是吗？资源组件也是这样的呢。

不像Mother和Father统管着资源组件的生命周期，Master统管着的是资源组件的活动周期。一个资源组件，参与着另一个资源组件所主控的活动，那么，在该活动中，就接受主控组件的调遣。直到该资源组件完成在改活动中的使命，退出该活动，并参与到其他的活动中，则表明资源组件更换了其Master。这和现实世界的职业人变换工作改老板的隐喻也是很贴切的。当然，每个资源组件也有机会成为其他资源组件的Master,只要我们在资源的活动逻辑中，定义了参与该活动的其他资源组件。

三树错合构建资源组件的复杂动态关系网

资源组件之间的三种关系，都是连续的一对多的关系，也就是说，就某类关系而言，资源组件之间都构成一个树的关系。这样，一个应用软件系统就有了至少有了三个相对独立的关系树的结构。由于这三个树结构都是叠加构建在每个资源组件之上的，因此，系统的全部的资源组件就将这三个树交织了起来，形成了一个有序而又复杂的，动静相宜的关系网。

Mother关系相对比较固定，只有Mother组件或子组件自身消亡时，其子组件的母子关系才断开，子组件的结构此时就只受自身演变的影响了。

Father关系相对比Mother关系灵活一些。在Father消亡时，可选择将子组件“托孤”给其他组件做子。如果选择不托孤，则子组件个跟随父组件消亡。

Master关系相对最灵活，通常，一个资源组件在一个时刻只有一个Master组件，也就是说，一个资源组件在一个时刻只参与一个资源活动。资源组件在资源活动之间的活动调度，则由活动规则自身来控制。因此，一个资源组件在某个时刻的Master组件是谁，实际是动态变化，不可预知的。

面向资源开发方法，正是靠实现了这个内部机理，从而带来软件系统的可演进性的。这也是面向资源的应用软件开发方法，从软件的角度实现平行演进系统的技术方案的核心。

邱嘉文

2014年12月于珠海诚开智能