MageTower 信息平台架构 – 万源归一

   

MageTower 信息平台架构 – 万源归一

 

魏可（ gaoxybb-wk@yahoo.com.cn）

 

接开篇，旅程第一站。

我要创建一个东西，用它来表达我要对付的信息。在面向对象（ OO ）的编程语言中，就是一个类。由于我们信息系统中大多要处理的就是单据，所以我把这个家伙称为 Bill 。当然你也可以用 Info 、或 Information 来表示。我希望这家伙能表达所有的信息。

它包括以下元素：

MageId  id – 信息的识别标识（ ID ）。

BillType  billType  –  信息的类型。在 billType 确定的情况下， id 具有唯一性； billType 和 id 的组合将在整个系统中构成一条信息的唯一性标识。

List  elements – 信息元素集合。这里面容纳了信息的全部内容，持久的或暂时的。

DataDictionary  dict – 数据字典。用于解释 elements 中的数据含义。比如你可以用中文或英文解释某个元素的意义，这样在一些情况下就具有了部分翻译的能力。不仅如此，解释的力量是无穷的，也是伟大的，比如，馒头血案，有人解释“恶搞”，而有人解释“无耻”；涨价被解释为“国际接轨”；家属免费坐地铁，更可以创造性地解释成“伟大的反恐义举”啊。在我的系统里，你想怎么解释，尽管换字典好了，不过，实际内容还是那个 elements 中的数据。

States  billstates – 状态集合。信息在被处理的过程中可能会有多种状态，甚至有些状态可能会是并存的。

Attribute attr – 属性。包括信息的创建、修改等操作过程中所涉及到的时间、地点、人物等资料；还包括我在开篇所提到的权限标签。

List  dataclasses – 信息类别集合。这里要注意与信息类型 billType 的区别，比如某一类型：“人物”中的一条信息，可以有很多类别：男人、女人、记者、工人、作家、 …… 反恐精英等。 在开篇中我提到万能分类法，所以一条信息中可以含有很多类别，而且并不限定哪方面的类别。在这里， dataclasses 直接包含或指向了这些类别，如果你觉得这种方法太直接，也可以用一种规则来替代它，就是告诉系统如何以及到哪里去找这些类别就可以了。

List  relations – 关联信息。在开篇中我提到“ 无限关联技术 ”，在这里将会使用。一条信息可以和其他任意多的信息，在任何意义上产生联系。 relations 将指明你所感兴趣的关联对象。当然，你也可以对所有关联对象有兴趣。 relations 不直接包含关联对象，而是用关联规则来描述所感兴趣的关联对象。因为，如果所读出的每一条信息，均要把它的关联对象一并读出，而关联对象还有其他关联，连环套连环，以致无穷也，这样，不大工夫，你的内存就会被挤爆掉。至于关联规则如何制定，日后再说。

Errors errors – 错误信息。在对信息的处理过程中，难免会产生这样那样的错误，这里将暂存这些错误信息，以供提醒和更正使用。

好了，该有的基本都有了。这个 Bill 将代表我以后想要处理的任何信息。也不用通过扩展或继承来写新的类了。以后，我的系统中的所有东西都围绕着他，为他服务，为他而疯狂。

那位说了，还没有讲方法呢。方法当然很重要，但在这里就不是最关键的了。因为有了它所包含的东西，你自然可以构造出必要的方法。无外乎把里面的东西读出来，写进去。其中常用到的就是把 elements 中的内容解析出来，解析的时候，将会用到字典，不同的字典将会赋予内容不同的含义。

那位还说了， OO 技术的最大优点是继承，人家都是有一个基类，然后扩展，你这样一个 Bill 搞定所有信息，不是有违 OO 技术的原则么？诚然， OO 技术乃人类科学的伟大创举，包括我使用和喜爱的 Java 。但是伟大和喜爱并不代表她就没有不足。我认为不能囿于其所有的原则。网上都有很多这方面的讨论。

我谨谈一点个人粗浅的看法。

我和很多人的看法一样，认为软件表达了编程人对客观世界的认识，在软件中我们设计了或表达了现实世界中的对应物。那么就 Java 而言，她的万物之本 Object 如何与现实世界对应？

可以想象， Object 对应于物理学中的基本粒子，我们的万事万物皆来源于此。可是我们知道的基本粒子并不只有一种，什么质子、中子、介子等等。但是有些物理学家在冥冥之中笃信有一种最最基本的粒子，由它构造了我们的世界，因此前赴后继、越钻越深，据说现在已经穷追到了夸克、胶子，也许伟大的终极发现指日可待。那就假设 Object 对应这个最最最基本粒子吧。我们知道基本粒子都有一种能级跳跃的本事，如果我们万事万物都继承于它们的话，那你我显然也能这么干（不知一人得道鸡犬升天算不算？）。你有没有试过？所以，我们万事万物不是继承于基本粒子，而是由基本粒子所组成，组成后就发生了质变，不是原来的东东了。因此 Object 不能对应基本粒子。

让我们来到精神世界，将 Object 对应于上帝。世界各国都有将灵性或物品当作神的化身的传说，而神显然又是上帝的化身。在中国有道生一、一生二、二生三、三生万物之说，道就是中国的上帝。而我们软件中的所有东东均来源于 Object ，显然 Object 可以对应于上帝。上帝的特点不仅大慈大悲，而且法力无边。可是我们的 Object 却相对弱智的多。在西方，有天赋人权之说。在中国，上天还赋予我们生存权、发展权，据说最近还多给了我们一种：和谐权。 Object 有此能耐么？ Object 仅有 8 种法力（方法），而且这 8 种法力还经常无用武之地。不仅如此，在我们的软件中，任何一个家伙，其法力都会大于他，至少也不亚于他。 Object 是我们软件中最笨拙、最愚蠢的家伙。如果将 Object 对应于上帝真是 OO 的本质的话，那这个愚笨的 Object 是否就是挚肘我们施展拳脚的根源？

也许以上都不对，再换一种视角： Object 只是我们对万事万物的一种最基本的抽象。这回总算说到点子上了。可是我们的世界总是先有万事万物，然后才能对其中的事物进行抽象。所谓： 横看成岭侧成峰。总是先有山在那里，从一个角度去看，我们抽象出“岭”，从另一个角度去看，我们抽象出“峰”，最后我们又进行更高级的抽象：有岭有峰谓之“山”。在软件世界中，则恰恰相反，我们必须先有抽象，然后再有具体实现。我们先期已经构造了“岭”和“峰”，有一天忽然发现其实更应该构造的是“山”，你说这“山”是继承“岭”还是继承“峰”？于是前功尽废，重新来过。 OO 的死穴昭然若揭。

困难压不倒英雄汉，死穴岂可点大师？大师谆谆教诲我们：要尽量针对接口编程，而非针对实现。也有称之为面向接口。接口这位类的表兄天生就是来化解死穴的。相对类而言，接口才是真正代表了抽象。你说“山”有岭之魂，那就实现一个“岭”的接口；你说“山”有 峰 之魄，那就再实现一个“ 峰 ”的接口。接口在 OO 家族中虽非直系宗亲，却是我最为敬仰的。看看接口在软件世界中所受到的顶礼膜拜，其程度远远甚于类。任意打开一个中间件的 API 说明，其中最为扎眼的就是接口。 OMG 的规范文本开口闭口皆为接口，类则黯然失色。作为类的最高领导， Object 的地位显然受到严峻挑战。可他还坐在那至高无上的皇位之上。名不正言不顺啊，怎一个愁字了得。

沉舟侧畔千帆过，死穴前头却萦愁。我能化解这千古愁吗？不才汗颜，我哪有这本事？除非我继承了基本粒子，来个能级跳跃。不过冥冥之中我可以有一个梦想，幻想在不久的将来，有一个小子，他实现了能级跳跃（没有继承基本粒子，大概接了口）。他创立了一种语言，不再面向对象，也不面向方面，而是面向上帝（饶恕我的不敬，阿门！）。所有的东东均为上帝的化身，所有的东东从它创立的那一刻起，便有了无限灵性的可能。我们在软件中编写的一切法术，均是属于上帝的，编得愈多，上帝的法力愈大。那位说了，这样的话，你的软件中就不需要其他东东了，所有事情均由上帝代劳可以了。此言差矣，让上帝一人干活，你怎能忍心？没有其他东东，岂不回到混沌世界？在那个世界，无须干任何活。为了抽象，为了表达现实世界的需要，我们和上帝都需要东东。上帝根据某个抽象概念，将必要的法力赋予他所看中的东东，这个东东于是就变成了那个概念所表达的东西了。一旦龙颜不悦，可以随时废了他的功力，他就又变成什么也不是的东东了。打一个现实一点的比方，有一部手机，仅能打电话和接电话。一日，上帝兴起，赋予了它拍照的法力，于是，它就变成了数码相机，同时也还是手机。还需要接口吗？问一问上帝，或查一查它的法力表，就知道它能代表什么概念了。

以上胡言了。

大胆，我看你的 Bill 就有取上帝而代之的图谋，知罪否？

黄天在上，日月可鉴，老臣我纵使有此贼心，也断无此贼胆，更无此贼能。上帝岂是好惹的？不过在适当的时候，为我的 Bill 赋予一点点灵性却也是一个不错的主意。