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

就像c/c++现在还没有over一样，还早啊

这种观点上的差异反映了我们对OO理解上的绝对差异，你的类比显示出将OO的适用范围扩大化的倾向，而我则认为OO并没有如此伟大，OO仅适用于某一特定应用范围，但是在该应用范围内，OO已经是非常出色的方案，不会有更完美的方案。

我所说的生物结构，指的是生物本体的组织结构，而不是物种之间的所谓层次关系，那些层次关系可以说是虚幻缥缈，说白了就是某些人的猜测。我们研究的是生物的躯体构造，这是大自然构造复杂系统的完美示例，因此将其作为参照来论证OO方法的优劣是再适合不过。过去的研究表明，无论是高级生物还是低级生物，无论是动物还是植物，都必然有一个基础单位来构造系统，一般而言这个基础单位被称为cell，cell指的并不是某个实体，而是一种结构关系，只要符合该结构的实体，我们都会称之为cell。OO也一样，object同样有固定的结构关系，属性、方法加边界构成了OO系统的基准单位，无论系统是简是繁，最终都必然是以object为单位构成，这种理念是OO第一个优胜的地方，这种设计并不是某个人异想天开幻想出来的，而是师从大自然的必然结果，这也是所谓的OO理论在n年前就被毙掉，OO却愈加蓬勃发展的缘故。

接口、泛型与重用(1)

http://spaces.msn.com/members/zbw25/Blog/cns!1pA6-3FOo9yNp_4lmEHxdDqA!272.entry

老庄，你的这篇文章我觉得有些地方写得不是很对，至少不是很好！

诚然，对于接口，现在有被滥用的趋势。 但是这种因为浅薄理解”面向接口编程“而导致的滥用并不能抹煞接口对于Java语言的贡献。
从老庄的论调中，似乎也有被误导的趋势。


下面就着我的一些实践经验来说一下关于接口的见解：

1） 接口是针对行为而不是数据Model的 ，动辄extract interface是一种显而易见的的滥用接口。

2）接口的行为必然会处理数据 ，接口通过参数和Return Object来建立数据与行为的关联。可以说，参数的设计与接口行为的设计密不可分。


接口在更高一种抽象级别上抽象了行为接口。这种级别的抽象是很有必要的。

---
到了Java，因为对于多继承的恐惧，Java完全摈弃了多重继承，这是Java被攻击得最多的地方，因为这样的单根继承，实在是因噎废食——因“怕被继承体系搞乱”废“更加方便道代码重用”。于是Java就说了：我们有一个“安全的”多重继承，叫做“接口”，这个接口，完全没有代码，只有说明，所以绝对安全，但是由能够实现多重继承的好处云云。
而事实上呢？多重继承的根本目的，并不是像Java所宣称的那样为了“同时继承多种类型”，而是为了“同时重用多组代码”。接口这一发明，完全不能达到多重继承的代码重用效果，却被宣称为多重继承的替代品。其实质是：“从一个发育不完全的实体，变成了一张彻底没有发育的皮”。
---

同意。抛弃多重继承 确实是 因噎废食。
我想，主要原因不是怕 程序员用不好，而是java 怕自己实现不好。单继承带来的实现难度已经不低了。
C++的多重继承实现，不同的编译器，编译结果都不一样。多重继承实现的难度太大，需要考虑的东西太多。如果加上多继承，java spec可能要多好几页。

---
于是Java就说了：我们有一个“安全的”多重继承，叫做“接口”，这个接口，完全没有代码，只有说明，所以绝对安全，但是由能够实现多重继承的好处云云。
---

java什么时候这么说了？我倒是不知道。:D

---
最为令人感到奇怪的，还不是“接口的出现”，而是“面向接口编程”的出现，Java被冠以“面向接口的语言”的美名，“面向接口设计”成了OO的设计原则之一，“针对抽象，不要针对具体”，成了OO名言之一。实在是......
---

“面向接口的语言”这个说法我也不知道.
“面向接口编程”、“针对抽象，不要针对具体”的含义 应该是"Programming By Contract"吧。这个说法早在Java产生之前就有了。C++, Java 的纯虚类也相当于interface。
从语法意义上来说，interface没有任何特殊的地方，和没有任何实现的纯虚父类没有区别。只是，在java里面，纯虚父类不能够多继承，而interface可以。
这是为了概念的清晰，做出的规定。

MS的COM组件是“面向接口编程”的经典。

------

咋整的呢？
庄子的blog里面含有非法字符，把版面搞乱了。我修改了好多次，才挽救回来。

看到现在，感觉每篇都点到即止，基本上都是侧重缺点论述，实际上大多数都是公认的一些缺陷，让人感觉在批判OO的一切，不过翻到庄在前面的论述：


感觉庄目前的所有批判都比较表面化，举例乐OO在各个方面的瑕疵，但是毕竟发明刀和枪并没有罪，而且刀和枪也是需要并且好用的，罪过在于使用它们杀人放火的人，（据说C++包含乐几乎一切，是给开发人员选择的权力，原话和出处忘乐，当然我还是比较喜欢大多数情况下不能选择的JAVA）
又想起以前在CSDN论坛上和人辩TDD应该如何做UNIT TEST（主要冲突在于TDD是不是应该完全只使用黑盒测试，我的观点是不能一概而轮，白盒还是大有用武之地），
最终对方说，你（就是我SWING）所说的只是局限在TDD上，TDD不能帮助开发人员避免那些不应该的陷阱，就说明这个方法是有问题的，应该明确了解其本质的情况下研究更好的方法。（大意是这样）
无奈地折服乐。

所以，希望庄能更突出你的论点，紧紧扣着论点来发挥，不然难免成大杂烩（毕竟本来的一篇文字就少）
（另外：其实现在中文比较烂的说，可能阅读理解上有问题是自己原因）

我认为庄某的问题，就是局限于未经考验的“学术眼光”，这是问题产生的一个主要根源（我也有类似的错误倾向，比如，用数学的眼光去看物理，尽管我数学并不好）。

当今可以获得“知识”的途径很多，从学校课堂上，认证和培训上，市面上大量涌现、令人目不暇接的计算机书籍中，你都可以得到。然而，这里面最核心的要素是自主思考。在这个过程中有大量的筛选和沉积，那些留下的部分应该是你从内心深处认同的，它几乎变成了你的一部分。

一个人能够做到大量、快速地阅读和接收新知识，同时不乏自主思考和创新能力，这两者并无必然矛盾。相比而言，我更看重后者。技术更新看起来如此之快，客观上也一种压迫人们的趋势，使之几乎来不及思考和消化，就"接收"了。有思考力的人会重新审视，产生反弹力。遗憾的是，受制于经验和其它多种因素，辨析出哪些是真正有价值的知识，往往并不容易。我说的其它因素包括教育的缺陷（教育应授人以渔而不应该盲从和灌输），环境和文化的影响（如不求甚解，肤浅的模仿和滥用到处发生的习气）等等。

所以我要强调自主思考的重要性，培养你的辨析力。这是一个长期的过程。大量的实践和思考并重。我所说的实践不仅是指项目中的实践，包括一切大大小小有关软件的实践活动，比如对于OO，你不断地写出小程序来验证你学习过程中的想法。你的功底将日渐增长。如果你想过多地依赖于阅读（即使是大师的著作）就能学到这些东西，很抱歉，我不得不说，希望渺茫。即使你看过10遍，也未必真正理解它。你需要做到以我为主，永远不要轻易接纳或相信什么。不象其它一些学科中的纯学术理论，在这个软件方法论世界中，没有实践支撑的纯粹理论以及理论家没有生存的土壤。

可以简单地说，有问题的或错误的认识的发生，往往与功底不够有关。我并非不尊重学术和学术上的讨论，而是，它其实要求非常高，要有极深的功底。否则，你很难能证明出什么，赞同或反对什么。早期的学术，包括可能的对于OO的否认（我只看到过早期人们对于OO的困惑，没有看到理论上对于OO否定的文章），以我的切身体会，我相信这样的理论必定存在漏洞，它一定忽视了什么，夸大或缩小了某些因素。 很多人都会犯这种错误，在他们的理论中没有考虑后来被证明的致命的要素（世界太复杂了，不要认为自己足够聪明）。OO世界的实际情况是其思想和实践先行，理论滞后。从OO一系列设计原则，以及设计模式的提出，我们已经看出了理论开始显露，有逐渐迈向成熟的趋势。

OO只是一种思想和方法论而已。方法论不象数学或物理定理/定律，只有对错之分。它只有好的和不好的，优秀的和糟糕的之分。而且往往都有适应条件。比如我说OO比面向过程好，对于一个复杂系统来说，因为我发现正确地应用OO将使系统更易于扩展和适应变化，更易于维护。

  我有一个未经证实的观点，如果接触OO是从Java，那么有可能得不到更深的体验。我知道这样说话不是很妥当。但是根据我的经历，和一些人的交流中，我知道对于一部分人来说，是这样的。事情往往是这样的：从一个已经发展到一个较高阶段的事物中，有些东西是得不到的。人们这个时候看到更多的是结果，却看不到演进的过程。

我还是建议，去精深地掌握一门如C++那样较为底层的OO语言。到什么程度呢？到你完全明白它的实现机制为止。虽然并非是必要条件，但若精深地掌握它将带来深远的好处。依此为根基，向上走，去运用OO去分析和解决问题。你将发现合理地运用OO有很多学问，很自然地，你将发现一系列OO设计原则、设计模式的价值。不过，OO不止这些东西，这些是浮出水面的。掌握其中的权衡，你将更深刻地理解OO。OO思想符合人类分析问题、解决问题的一般习惯。你将发现OO有很好的表现能力和适应能力，尽管它有不足之处。你恐怕仍然较长时间都会感到，难以找到比它更好的做事方式。

别的不多说了，以后有机会向你多多讨教C++的问题。



这里就说一个很奇怪的逻辑，OO语言为什么还要和底层有那么深的瓜葛呢？面向对象的本意，不就是试图将程序员从底层开发的烦琐中搭救出来吗？

最近看了看<敲响OO时代的丧钟！>一贴 ，倍感惭愧，看着大家的基础功底都是如此深厚，知识表示，词法分析，......自己只懂得一些应用知识，看起来都觉得费力，但又忍不住想发表自己的意见：只能说些大白话了，希望大家不要嘲笑才好：
首先做应用（本人的所说的应用都是些信息系统之类的对现实手工的模拟，在高深点也就是整理手工流程，优化，再设计了。）么，先来看看一般的用例描述：一般都是第一步.....第二步 ........第三步.......看了写不多的关于用例的书一般都是这样，应该没错吧，为什么？要把一件事情说清楚，用文章写出来或是用嘴巴说出来都是线性的表达。一二三四大家都能明白。而且清楚。这可可能就是大家说得 “过程” 其实面向过程精髓就是在于 顺序 分支 循环 一步一步地把问题讲清楚。很自然。
过程化的方式死了么？ 没有 ？其实现在很多打着面向对象旗号的人，仍然自然不自然的甚至是不可避免的用到过程化的方法，稍微与各例子 工作流是什么？就是把一个工作的流程描述清楚么！过程化的方式已经变成了血液流淌在你的身体里了，只不过外面包了皮肤，不容易见到罢了！
那么面向对象和过程化冲突么？我看没有，对象只不过使得在描述过程的过程中显得更简洁，这不是一小步的进步，应该说是一大步：用面向对象的极端的口号来说everything is a object!但是这些对象如何完成某一个工作呢，如何协作，调用的顺序呢还不是有过程化的方式描述出来的。
其实面向对象没有什么神奇的：它只不过把我们所要描述的事物名词化，首先定义一堆名词，这些名词也就是大家公共所接受的概念，内涵了名词与大家的协议，举个例子更清楚些：
1）填写好选课单，交给老师确认。
为什么短短一句话就能让大家有个比较清楚的了解？首先我这句话定义了几个对象：选课单，老师。这两个对象的内涵外延大家一般比较清楚，（看然可以更加清楚一点 老师前面加修饰语<这个也可以继承>）如果没有这两个定义呢？我们该如何说？
在选课单上填好 姓名，学号，所选的课程，老师，然后交给。。。。。。对象的好处是把这些细节自包含了，大家交流就比较清楚了。但是他本身是不排斥过程的。所以面向对象更自然清楚。正是这样对象就自然有了封装性（名词的字描述性）继承（自行车比车的描述更具体）多态（我要车去北京 ：汽车 火车 自行车 都可以），所以对象只是在用过程描述是更精炼 不可能替代过程。
过程没有死，对象也挺有用，以前的程序比较简单所以用到名词定义的表较少，反复在不同的系统中描述还不算太繁，现在的系统要描述的内容太多，多点名词，更容易让大家理解。
既然名词大家现在还用着，估计对象的丧钟还不太容易敲响。只是会越来越规范，到了一定的程度会像字典一样标准化，姑且称为名词的协议把。
下面我想在罗嗦两句AOP
AOP我的理解就是对<对象>进行批处理，是对过程化批处理的进步，但也是进一度对过程化的肯定。AOP就是在合时的条件，对于合时的对象方法进行操作，使动态化的批处理！
过程不会死，对象不会死 AOP会更广泛的应用！

我说了，这并非一定要如此。但是，道理很明显，对于一个事物，如果你愈能深入地掌握它，你的评述将会愈加客观和有力度，因为你很清楚它是什么，它为何出现，如何实现它，它的优点和缺点。无论你是赞成，还是反对。

我以前好像听人说过，你掌握C++越深，那么转向Java就越难。反而一个初学编程的比你更能适应。让我怎么说好呢？至少对我来说完全不是这样。如果你对一个东西掌握的如此透析，你还迷信这种说法？只有对一门东西掌握的一知半解，才会有这种担心，因为你并没有真正掌握。而我，却很可能知道你的盲点和误解在哪里。