MageTower
信息平台架构
–
万源归一
接开篇,旅程第一站。
我要创建一个东西,用它来表达我要对付的信息。在面向对象(
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
赋予一点点灵性却也是一个不错的主意。