敲响OO时代的丧钟！——DJ对于数据持久化的支持(3)

我们可以通过“种＋属差”来定义一个新的属吗？定义成立的前提是什么？先要有种的定义。然后才可能有属的定义。种的定义又是哪里来的呢？在一个种的概念之上，必然存在一个更普遍的种，一个更大的范畴。在亚里斯多德来说，在所有的种之上的种是“存在”，而存在是无法被定义的。而在面向对象的哲学里，即使是这一个最基本的哲学困境也被忽略了，无法被定义的概念，被代换为无需由程序员定义的概念（Object）。
首先在我对亚里斯多德的“存在”理解是是种的极限，你永远都不可能达到它。在现代西方科学中将研究对象与周围的环境隔离而对孤立对象进行研究是一种基本的思想方法，如果不是伽利略将这种方法引入到科学研究的话，我们可能现在还搞不清重的物体和轻的物体在从高处落体时谁先落地，我们在研究信息对象时我们也是采用的这种方法，我们并不是否认存在一个更普遍的种而是将我们所不关心的种隔离在我们的研究边界之外而已，也就是讲更普遍种中对我们不感兴趣的部分隔离在边界之外，object正是对这更普遍的种的一种抽象而不是对其忽略, OO<>形而上学! OO只是形而上学思想的一个应用而已。

而在面向对象的哲学里，种的共性就是基类所定义的“属性与方法”，而属的个性，就是对于基类的扩展。种＋属差”变成了“公用代码＋扩展代码”。
一个对象对应于形而上学的实体，它(本质上)是什么?这就要给一个东西下定义，也就是揭示其本质。下定义必须采取"种加属差"的方式正如亚里士多德指出定义不可过宽或过窄，既不能适用于别的对象，也不能漏掉要说明的对象；应当清晰和精确，不能有多余的东西；不应当是否定性的，也不能循环定义；定义必须是唯一的，所以这从一个侧面可以看到面向对象的分析是有相当的难度的智力活动。在面向对象的分析中，种可以认为就是class的概念，而属差就是其属性和方法，他们被用来表达属差，所以“种＋属差”根本不是“公用代码＋扩展代码“，无论公用代码或者是扩展代码都是属差的表述。

当概念定义这样一个“问题域的描述手段”，演变成“减少重复代码原则”之后。Class继承的概念就越发的模糊不清了。
由于通过分析可以很好地理清实体之间的关系，其必然的结果就是减少重复代码，减少重复代码应该只是面向对象分析带来的结果而并非面向对象分析的目的。

1、面向对象原本声称的描述真实世界的目标，采用的工具却是朴素的“种加属差”的方式。
面向对象的方法没有讲过它可以解决世界上所有问题，用种加属差已经可以描述我们日常遇到许多问题，而且实践证明其描述在一定的范围之内是有效正确的，这也证明了“种加属差”的工具在信息科学中还是有效的。面向对象的方法可以讲是实践走在理论之前的典范之一，他还需要做大量的理论上的完善，才能使其建筑在坚实的逻辑基础之上，就象关系数据库。

2、面向对象分析中，发现具体的对象还算是容易的，发现“种”的概念却是困难的。
这并不是面向对象的过错，是使用这种工具的人的对问题的认知所决定的，这在所有的研究领域都有的问题

3、在实际应用中，种概念的发现与定义，被偷换为公共代码的抽取。
不对，代码只是在计算机的世界当中对实体的表述语言，而不是对种的发现和定义，发现种属是分析人员的认知，描述性的工具并不能代替思考，正如我们可以用矩阵表达许多问题，但是怎么正确的表达是建立模型的人所要做的工作，其结果可能是正确的也可能是错误的。

4、由于基类的定义的随意性，导致子类不但可以扩展基类的行为与特性，还可以覆盖（改变）基类的行为与特性。
在一定的范围内对基类行为和特性的覆盖可以认为是一种扩展。一种属差的表现。

5、由于哲学概念的与开发概念的混淆，使得在OO领域IS-A、Has-A、Like-A成为最为绕人的概念。
这取决于分析人员对问题的认知程度而不是方法本身的问题，即使不用面向对象的方法，不在信息学领域，我们在研究中也常常会有一样的困惑。

我只需要证明“面向对象背后的那个形而上学基础是不正确的、是不适用于软件开发的。”
我看了全文作者没有证明"形而上学基础是不正确的、是不适用于软件开发的".
其实如果我们进一步思考一下我们会发现关系数据库，实体分析方法其实也暗合形而上学思想，只是表现的形式不同，如果有形而上学思想的东西在软件世界是死路一条的话，关系数据库我们也该为它敲响丧钟了。（鼓吹数据库过时论的人该高兴了）

至于<<丧钟>>中引用waterbird《OO, OO以后, 及其极限》的思想认为OO是以原子论为基础的我是更不同意了。在OO中没有人会认为对象是不可分解的原子，只是在我们研究的问题当中我们没有必要加以分解我们就可以完成我们对问题的描述，比如我们在考虑一个人事描述一个雇员的时候我们是否有必要分解描述这个雇员的心脏呢？完全没有必要，这又是近代研究时划定研究边界的思想的体现。如果OO和原子论没有联系，那原子论的破产又和OO的丧钟有什么联系呢？那么哲学破绽在那里呢？

“存在”在哲学家那里是有点神圣性的，“不可定义”的。“存在的特性就是存在着”。“Object”在OO语言里，就是一个基类，比如Java里的Object，有一堆公用的方法而已。这中间有一个深刻的矛盾，可以说OO刻意忽略了实体定义的困难。而哲学是早就意识到了这个问题的。至于你举的伽利略的例子，我认为有点偏了。

我理解的种和属差和你的理解有不同。
种就可以算是基类。种是一个大的概念，有其属性与方法。
属是子类，是继承了种的特性，但又有自身特性。
属差，就是子类所扩展出来的特性。

特别是这段话：定义不可过宽或过窄，既不能适用于别的对象，也不能漏掉要说明的对象；应当清晰和精确，不能有多余的东西；不应当是否定性的，也不能循环定义；定义必须是唯一的，所以这从一个侧面可以看到面向对象的分析是有相当的难度的智力活动。

这是我非常同意的、正确的、面向对象的分析方法。
然而啊，然而，因为理解困难，思路不清，性能限制，减少代码冗余的目标干扰等等原因，有太多的面向对象分析不是这么搞的。

 


如果我把“公共代码的抽取”，改写成“公共特性的发现”呢？这是不是分析人员的工作呢？分析人员如果不深刻的理解代码的编写技巧，有如何能够“发现公共特性”呢？这其中同样有一个深刻的矛盾存在着。

如果Class A的run()方法与Class B的run()方法只有名字是一样的，实际的行为完全不同。
我们以什么理由让Class B去继承Class A呢？

原子论的含义主要不在于“不可分解”上。而在于“构成世界”上。
认为世界完全由同一种概念定义的原子——“水、火、气”之类——构成。这是原子论的最基础的假设。“一切皆是对象”正是“一切皆由原子构成”的翻版。

我当然知道应该是这样说。那么好了，“转帐”这件事情是非常重要的事情，是系统真正在做的事情。类似的，“记录日志”这件事情是重要的，“日志工具”并不重要；“管理事务”这件事情是重要的，“事务基础设施”（例如JTA/JTS）并不重要；“安全检查”这件事情是重要的，“安全基础设施”（例如JAAS）并不重要。而OO在这些时候，建模了不那么重要的“用什么东西做”，对重要的“做什么”却没有建模。明白我的意思了么？

事实上，我们猜想是，如果没有知识表示和自动推力工作的帮助，这些问题(指类，继承)是无法仅仅通过计算机语言设计的方式来处理的

关于这个“矩形和正方形”，我现在越来越倾向于将它视为面向对象的本质缺陷。

前一阵子不自量力，想要捣腾出一篇关于知识表示的论文来，于是去买了一本这方面的经典著作，John. F. Sowa 的《知识表示》回来看。没看几章，天旋地转，只能放弃了，但也稍稍有所收获。它详细介绍了人们表示“知识”的种种尝试，介绍最多的就是带类型的一阶谓词逻辑，其中的类型系统建立在“Ontology”的基础之上，而这个“Ontology”，就是一种对概念的分类学。举个例子来说，这样一种分类：

                                           ______ 存在 ________
                                          |                  |
                               _____ 实体 ______              灵魂
                              |              |
                  _____ 活物 ______          非活物
                 |                    |
        ___ 动物 ___             植物
       |             |
     人类            野兽

看着是不是很眼熟？和我们在面向对象里面玩的“矩形和正方形”这样的类集继承体系很像吧？这里同样有父子类型的概念，其中“存在”是“实体”和“灵魂”的父类型，而“动物”和“植物”是“活物”的子类型，而且由于要拿 Ontology 的类型系统来作为推理基础的，也有“对父类型成立的谓词，对子类型同样成立”这样让我们看着更加眼熟的规则。我相信，面向对象类型系统的思想基础，有很大一块来自这个东西。

事实上 Ontology 这个东西人们已经研究了两千多年。上面这个分类方法和父子类型的术语来自亚里士多德，这棵树来自中世纪的逻辑学家 Peter of Spain （1239），当然我做了不少简化。这么多年来无数人都在这上面投入了很多心血，今天还有一个巨大的项目，希望将整个世界上所有的事物概念都纳入一个 Ontology 树里，而各种面对一个具体领域的 Ontology 更是不计其数。然而直到今天，知识表示仍然是难题。

这里面有一大条就是 Ontology 的分类是静态的，无法反应状态变化（嘻嘻，看来 immuntable 确实有道理）。比方说，我们可以把人分成儿童、青年人、中年人、老年人。显然，对“人”成立的事情，对儿童、青年人、中年人、老年人统统都成立，而且这四个子类型互不相交（这里不考虑模糊逻辑，:D ）。但问题就在于，对于一个人来说，随着时间的流逝，他会从儿童变成青年，从青年变成中年，从中年变成老年，这样一来，在以此为基础进行推理的时候，就有大麻烦了 —— 这个和我们的“矩形和正方形”的问题非常类似。

对此有什么很好的解决办法吗？事实上是没有，至少在我浅薄的知识范围之内是没有。我们所能做的就是尽可能地在设计 Ontology 和设计类层次体系的时候小心从事，尽可能避开这样见鬼的问题。

就我个人来说，比较倾向于认为这条最终是走不通的死路，人是从事物的特征与属性归纳出它的“类型”，而不是相反。某种意义上说，“类型”是为了节省描述时间而产生的 …… 唔，这个太远了，所以就此打住。

老庄，你不要写了。实在看不下去了，为了不浪费大家的时间，这个问题还是俺来说吧。

第一，我可以很负责的说,OO的，70年代成型，80年代在理论基础上就给人毙掉。从这种意义上说不是OO死不死的问题，而是OO还活着么？当然理论基础给人毙掉，不是说没有用。

第三, 凡是觉得自己在软件设计上有啥洞见的，请先翻阅SICP，如果SICP上写了的，说明你生不逢时，如果SICP没写，基本上可以断定是在错的。

相关参考:
1.SICP 第二章 2.5:构造数据抽象

这句话，在SICP edition 1，81年版中就存在了，也就是说基本上67年simula成型，70年代OO完善，到了80年代初就被毙掉了。所以以前我一直在想OO那么成熟了，为何SICP到现在还是死不悔改捣鼓FP呢怎么着也得与时具进搞点comm-lisp的OO特性不是？后来再仔细看到这一段，顿时就把我椅子上轰至桌面以下，并得出两个结论，第一怀疑SICP之前首先要怀疑自己是不是脑袋进水了。第二，SICP是值得重复，重复再重复读的书，习题，注释一个都不能放过。当然为何OO仍然会用到现在又是另外一回事情。

Developing a useful, general framework for expressing the relations among different types of entities (what philosophers call "ontology'') seems intractably difficult. The main difference between the confusion that existed ten years ago and the confusion that exists now is that now a variety of inadequate ontological theories have been embodied in a plethora of correspondingly inadequate programming languages. For example, much of the complexity of object-oriented programming languages -- and the subtle and confusing differences among contemporary object-oriented languages -- centers on the treatment of generic operations on interrelated types. Our own discussion of computational objects in chapter 3 avoids these issues entirely. Readers familiar with object-oriented programming will notice that we have much to say in chapter 3 about local state, but we do not even mention "classes'' or "inheritance.'' In fact, we suspect that these problems cannot be adequately addressed in terms of computer-language design alone, without also drawing on work in knowledge representation and automated reasoning.

2.关于知识表示，准备引用前人Elminster的名言，

其实维特根斯坦自己也很犹豫，他在笔记中写道：“我们的困难是，我们总说到简单对象，却举不出一个实例来。