文章, 很有点意思, 简单的介绍一下, 看大家有什么想法.
1. 面向对象技术事实上没有实现当初人们的预期, 事实上直到今天, 多数的成功软件也不是真正
按照标准的OO技术开发的. 而且从OOA到OOD再到OOP, 已经形成了一套庞大的, 复杂的体系,
对各个阶段人员的素质都有着比以前更高的要求. 从某种意义上讲, OOT不是降低了软件开发
的难度, 而是大大提高了这个难度. 国内的各种信息来源中, 一直看不到对这个问题的反思,
清一色的高唱颂歌. 而IEEE Software早在98年就有不少文章对此提出思考, 主要观点有:
* 通常所说的"OO更符合人们的自然思维方式"的论调是错误的, 人们面对实际问题时, 并不习惯
用OO的模式思考问题
* 经过详细统计, OOP程序中错误率平均比面向过程程序的错误率高15%
* OOA/OOD太困难, 简直是折磨人(原文很有意思, 有一句是Paralysis to analysis, 分析麻痹症)
* OOA/OOD/OOP关注的主要是软件开发过程中的问题, 并且建立了一套庞大的体系. 但事实上软件
开发过程只占软件生命周期的30%甚至更少. 所以OO技术错误地引导了人们把大量精力投入到次
要的问题上.
* 面向对象走得太远, 实际上"基于对象, 强调封装"的语言就足以满足需要. 例如美国军方早在
70年代末/80时年代初就成功开发几个千万行规模的军用软件, 使用的是基于对象的Ada语言.
继承不如聚合, 继承实现不如继承接口, 多态性带来的麻烦比产生的效益多, 现在软件发展走
向组件化就是最好的说明. 又一篇文章好像是说: UML生不逢时, 才面世就快过时了.
2. C++语言是一种糟糕的语言(这是不少作者的观点, 其中最有名的是斯坦福的教授Ullman), 除了
少数靠写C++书籍的人(注意不是用C++做项目的人)之外, 几乎人人都hate, 这正是JAVA走红的
一个重要原因. 用C++写程序, 哪怕是很小的程序, 都要求编程者同时出任program manager,
这样使得人们没法把注意力放在要解决的问题本身, 而是整天为C++的那些晦涩的问题心力交瘁.
3. Java现在的地位跟它的实际能力不相称, 早晚会从高峰跌下来.
我觉得阅读外刊很有意思, 完全不想国内杂志文章那样四平八稳, 将就辩证分析, 而是明枪明刀,
观点鲜明, 言语尖刻, 读的很过瘾. 以后我会经常去看, 推荐有条件的程序员们都抽出一些时间来
读一些外刊.
