《对象揭密：Java，Eiffel和C++》勘误与评述

《对象揭密：Java，Eiffel和C++》勘误与评述

       本书原名：《Objects Unencapsulated：Java，Eiffel，and  C++》，作者Ian Joyner，是鲍志云翻译的，2003年7月人民邮电出版社出版。

首先说说对整本书的评价。这本书并不象媒体或者什么其它方式对外界宣布的那样：比较这三种流行的面向对象语言的。其实这本书是从面向对象设计的角度谈面向对象语言应该怎样设计，以及这些设计可能会碰到的问题，涉及的内容非常全面。当然它的立足点需要这样一些实践语言来作为例子，证明作者自己的观点。其中，我们可以看到即使是像Ian Joyner这样的面向对象大师，好像也有在细节位置出现问题的时候（当然也可能是鲍志云翻译的错误）。从中可以看出：面向对象思想其实与具体语言的具体语法细节和表达在很多地方并没有什么联系，特别是和C++这样复杂的语言。

尽管作者说他并不是为Eiffel语言作辩护，但是，作者对Java和C++语言还是有诸多挑剔的。其实Java在书中的角色很小，被批评的自然主要就是C++了。当然大多数观点我还是同意的，但是里面有些批评难免让人觉得偏颇。例如对Java中的接口，对C++中的隔离等等。

书中有基础概念性的错误，我不知道是作者本来就有的，还是鲍志云翻译的错误。

不过，这本书虽然在内容上很全面，但是有几个错误是不能容忍的。例如：译者序中RL7“使用”前面缺少了“避免”两个字。虽然这个缺失很小，但是，这本书的价值，就因为这两个字，没有了任何价值。如果大家按照鲍志云的意思，那么就是鼓励使用书中提到的所有不好的特性。其实意思刚好相反，我们反对使用书中提到的那些不好的特性。就因为这两个字，我觉得翻译者的水平大有问题，还不说这是他翻译的第一本书。

    下面就给出我认为不对的地方，观点是个人的，可以不必完全一致！不过，里面有几个概念性的错误，我会特别指出，注意这些就是不可容忍的错误。

1    译者的话P1 RL7  “使用”－>避免使用

2     P8  “自洽”－>自协调

3     P25  L2  －>的

4     P32  L10 好像没有“1950年代”这种写法吧？

5     P43  L3  ？

6     P56  RL12     “>=”－>“<=”(这个地方真是一个低级错误)

7     P57  RL1“存在”也是量词运算符   （这里是一个概念性的错误）

8     P58  L7  “提入”－>“提出”

9     P60  L12 “ADC”－>“IDC”

10    P60 译注：这里译者明知有错也不改正，难道国内的技术人员崇洋媚外到了这种地步？（这里提一句，孟岩也是这样，就在译注中说明一下，书中错误居然也堂而皇之的保留）Ian Joyner大师也有这种低级错误，呵呵！

11    P73  RL4删除“的”

12    P73～74 不知所谓

13    P96 L9   删除“所”

14    P97  RL2“穷亲戚”具体指什么？

15    P98 “译注1”有所偏颇，从表达的整体上说，等价

16    P116       RL5“组合”－>与前文中的“聚合”不一致

17    P122      “融合”－>混入（设计模式中这样翻译的）

18    P123       RL4“得……”不知所谓

19      P127～128问题同10

20      P130       L8   不知所谓

21    P121       S3  同上

22    P135       L2～3    同上

23    P147       RL10     “必要”－>“必须”

24    P173      定义第二行   “Formal-generics”－>Formal-generic     这里居然连EBNF都写错了，并且还是定义，错的太离谱了

25    P178       L6  “胀”－>“膨胀”

26    P186       L5 L7     参考不是完整形式

27    P194       RS3是不是概念上完全有错误？友元和内联相似吗？

28    P212       L4  “不定式”－>“不变式”

29    P214       RL5“Eiffel”－>“Java” 这里居然连批判得语言都写错了，无言

30      P233 L11 “发”－>“发现”

31    P234       L3  “变量类型”签名和变量类型有关系吗？

32    P242       RL2第二个“抗变”－>“协变”（这里是一个概念性的错误）

33    P302       L10 “到一些”－>“一些”

34    P310       RL6“不能证明”      这里错误无法改正，这是一个巨大的概念性错误。从中可以看出Ian Joyner在理论上的欠缺，难道是7年前这个问题没有解决？？？现在程序的正确性是可以证明的，但是证明的代价高昂，所以只有核心的系统程序和关系到生命安全的程序才可能通过这种手段来保证程序的正确性。

35    P326       L4  “破化”－>“破坏”

36    P326       RL1“BITN”是什么？

37    P329      用两种方式做同一件事（这里应该是实际的问题，Eiffel违反了自己的设计原则，呵呵！）

38    P364       RL10     删除“得”

39   参考书目      “DeMarco”换行居然中间没有连字号

by：kangtian0

Blog：http://blog.csdn.net/kangtian0