空间、运动(时间)以及程序员

空间就是目录,由0 1堆出来的幂集

目录树中出现的节点有很多种,有ResourceType、Field、Dic、DicItem、Function、Organization、AppSystem等,这些catalog节点记录存在的意义是可以提供一套一致的方法去管理和使用它们。比如账户节点下的账户审核状态字典,这个字典里枚举出来的值也可以在编程的时候去在程序里写死,或者写个Enum类型枚举这些取值,但是那样不灵活。它们都一致的出现在Catalog目录树上是为了统一管理,良好的管理,统一运行。

空间堆积原则,遵循构造定律,最大限度节省脑力

我们的系统中可能并没有Person模型,系统内可以并不显式的对应有Person“模型”,但是我们最好对应有Person“概念”,我们建立人的性别字典的时候我们最好先建立一个Person节点,然后在Person节点下建立Gender字典。我们建立一个Person节点,然后在Person节点下建立了Gender字典。我们使用这个字典的时候可以直接从头脑中找到这个人类性别字典在目录树上的索引码,我们可以直接通过“Person.Gender”去索引这个性别字典,因为建立这个字典的时候我们考虑了足够多,这个字典不会随着我们的系统的改变而改变。除非人会出现第三种性别这个人的性别字典才会改变,这个A系统我们通过“Person.Gender”索引人的性别字典,换做B系统我们一样使用同样的编码。我们不编码为Employee.Gender,不编码为User.Gender,不编码为Customer.Gender,我们编码为Person.Gender,虽然我们的系统中并没有Person模型,并没有个Person Class。

程序员脑子里不应该只有string、int、boolean等目录节点
这群目录树可以帮助我们尽量避免C硬编码,我们尽量通过那些Catalog目录树上记录的信息去实现我们的逻辑,我们写代码的时候随时应想着那个Catalog目录树上有什么信息,随时想着借助目录树上的信息实现逻辑,那棵目录树上的内容不止可以被C代码访问,也可以被嵌入的javascript和xacml等脚本访问。

我们程序员写代码的时候可以写“Person.Gender”这样的字符串,通过这个字符串索引到性别字典,但是系统运行的时候在机器中是使用的Guid。只有与程序员打交到的时候才是可读的字符串,与最终用户打交道的时候是可读的汉字“男"。但是考虑到目录树的层级性,目录树上的节点的编码都是有层级的,都是类似"Anycmd.Person.Gender.Nan"这样的层级结构,编码上记录了层级。有时候这些层级结构会有用,比如组织结构的层级就是有用的,在数据库中我们会使用like '1001%'来筛选一个组织结构的下级组织结构,这种情况又需要我们直接存储这种有层级的组织结构编码而不是它的Guid。而字典可以存储Guid,因为字典没有层级。

把握好结构和运动,不要人为制造一团乱麻的图形
还有一个问题是这样:Employee、User、Customer是否要继承Person呢?Employee、User、Customer节点是否要作为Person节点的子节点出现在Person节点之下呢?
不需要。所有促使我们分析问题时往图的方向一团乱麻的都是因为运动,因为运动需要图,结构和运动这两个维度交差在一起时容易让我们一团乱麻。应对这个困难的办法可能是:不要视图在结构树上“显式”运动树(运行时树)。
Employee和User和Customer并非一定是人。计算机世界不是在完整模拟现实世界,计算机中的Person、User、Employee、Customer都不是完整的本神,它们都是分神,都是外部事物在计算机中的投影,计算机中的投影不具有本神完整的信息,也不需要具有完整的信息。Employee和User和Customer节点下也可以有Sex”字段“,只不过是把这个字段的值域绑定在Person节点下的Person.Gender字典上而已。

图形是短暂的,树形是常态的

静态的结构树投影在动态的运动树上的影子已经不是树形,动态的运动树投影在静态结构树上的影子也不再是树形。两者的维度混合在一起时是图形,是在树的局部制造的通路,通路中奔跑着的是携带着信息的能量,能量之所以在通路中奔跑是因为通路两端存在不等(差、场),携带信息的能量移动到达目的后,控制器(我们程序员书写的代码)在通路的某个地点又将通路断掉,从而世界再次回到稳定的树形。整个过程消耗了能量,所以只要能量源源不断的输入进去的话,我们的系统应该会一直持续下去。不仅消耗了电能,更重要的是消耗了程序员的能量。

个体的知识殿堂会与群体交集的知识殿堂有差别。我的知识殿堂尚不够良好,等足够良好了会将它往集体交集的知识殿堂做投影,更换词汇表达。