《对象揭秘:Java,Eiffel和C++》

http://www.cnforyou.com/query/bookdetail.asp?viBookCode=9163

毫无疑问，你现在正站在书店里，犹豫着有何充分理由要舍弃书架上充斥视野的其余关于C++、Java的书，以及（较少量的）Eiffel的书而购买本书。另一种可能性是你已经买了这本书，而正在考虑是不是该读下去。但是，这还只是前言，不是吗？通常而言，人们可不会有兴致来读前言--除了站在书店里的时候。所以，你大概可以省下读剩余部分的时间而直接决定购买你手上的这本书了 --要知道，这本书可是"三合一"的，而且不比其他书厚，甚至可能比大多数书还要薄一点。我想许多读者都会和我有共鸣：我们很少有耐心读完那些500页以上的大砖头。另外，本书可不是简单的"三语合订本"，而是告诉了你这些编程语言的共同点、不同点、各自的长处和短处；并且实事求是地评价了它们能够在哪些方面、在何种程度上满足你开发高质量软件系统的需要。


本书持批判的眼光，因为映入我们视野的是长期困扰我们的问题--正是这些问题使得编程任务变得不必要的艰难；正是这些问题使得"软件危机"的梦魇长期挥之不去。这些问题蛰伏于当今的编程实践之中，到了必须解决它们的时候了。对这些问题开刀可能会牵涉到流行编程语言的许多方面，这也意味着我们可能会不被某些阵营所接受。但无论如何，我们必须认识到，没有完美的技术。为了进步，我们必须有除旧迎新的精神。

本书不会教你任何一种编程语言，而是专注于比较语言特性的共同点和不同点，力图使你对编程语言有更深的理解，一如我在多年的编程实践中所获得的。在那些年里，我积累了许多对于编程语言的深层认识，不仅是本书中提到的语言，还包括其他许多语言；我也曾看到过太多的由语言而起的争执，其中许多毫无意义。

许多关于编程语言的书籍都在指导你如何躲过语言中的陷阱（traps），绕过语言的缺陷（pitfalls）。当然了，许多编程新手都有学习这些"秘诀"的需求，以登上"专家级程序员"的台阶。有太多太多的书籍利用了人们这样的需求。对于"潜在陷阱"的"警告"是C++著作的一大特色：Bjarne Stroustrup的书中就包含了许多这样的"告诫"，而Scott Meyers的书则给出了更多。他们这样为C++辩护：只要你知道了需要避免的问题，那么万事无恙。而本书采取了一种不同的（也许没那么流行的）观点：警告并不够，语言本身就应该被设计得更为健壮。购车的人可不会对汽车销售商的"警告和劝诫"买账--你听过谁这样宣传自己的汽车吗？"警告：本车型驾驶途中偶尔会向左猛偏；如果从Amalfi开往Sorrento，它会爆炸……"。本书力图拨开编程语言和面向对象技术由市场炒作而蒙上的迷雾，直指两者的本源真理。

市场炒作（hype）的一大来源是人们常常和"最新技术"闪电恋爱。我们深深地迷恋计算机，因为我们亲眼所见它们是多么强有力。我们特别会对自己使用的第一项技术产品一见钟情。很自然地，我们很爱自己的第一辆车，但是该发生的总会发生--有一天，我们发现应该换新车了，否则就不得不花一大笔钱来维护那辆老古董。当然，不断地更新换代正是发烧一族想要的，但对于只是将车当作一种实用的交通工具的人来说，情况就并非如此了。计算机行业已经为维护超期运行的系统而付出了太大的代价--典型的例子是"千年虫"问题。

人们也趋向于钟情具有较多用户基础的成熟技术，因为这使他们觉得自己属于一个更大的文化群体。这倒未必是坏现象，但当"强势文化"开始欺凌小群体时，当对某种技术的"忠诚"阻碍新技术的发展、窒息创新时，这种"随主流"的现象就必须受到批判了。在科学史上，这样的现象并不罕见：人们竭力保护已经建立的错误观念，只是为了保护某一权力集团的既得利益不受损害。在计算机行业，这样的权力集团更为强有力，在经济上也占有有利的地位。人们也许会将伽利略看作是这种现象的典型受害者，但在当时，对伽利略犯下罪行的那些人，可是被视为最为聪明也是最受尊敬的精英人物。

本书的立场是，技术必须不断地被重新评价，这样它们才能进步。我们必须看到并承认现行技术的缺陷，无论我们是多么地为它们所深深陶醉。被观察到的缺陷，毫无疑问，对于某些不断地释放烟雾以遮盖事实真相的人而言是一剂苦药--这样的抵抗是业内常见的"宗教战争"之源。"宗教战争"会毁了我们的专业精神！本书专注于编程语言技术，将三种广为人知的语言作为评论的基础。其余的技术，只要业界存在相关的市场炒作现象，也需要重新评价。

市场炒作非常有助于市场商人提升公众对他们产品的注意力。我最近曾听一位时装业营销人士说过，一件白衬衫不过是一件白衬衫；但一件经过市场炒作的白衬衫是你想买的白衬衫。我们不应谴责那些采用市场炒作手段的人，因为想要切入一个已有某种具极高用户忠诚度的产品居统治地位的市场，这是必然的选择。但我们对技术的正确评价不应该受这些市场手段或者产品忠诚度的影响。计算机行业是最具忠诚度的行业之一。作为消费者，我们需要对不实市场宣传造成的假象多加小心。

本书的主要目的是比较三种语言：C++、Java和Eiffel。据我所知，没有其他书用这种方式来比较语言--因为这并非易事。本书的最初形态是一篇关于C++的论文，但后来Java出现了，解决了C++的不少问题；所以直接将Java和C++作比较看上去是个好主意。既然我已经把Java牵扯进来了，那么再与其他语言比较看上去也是个不错的主意。Eiffel是显然的选择，因为在许多地方它与C++和Java具有可比性。我还想将其他语言如Smalltalk、Beta、Oberon作为比较者，但是这些语言有更多的不同，而且三种语言作比较已经提供了足够的材料。

本书的另一独到之处是，以实用主义的目光来看待语言功能，并专注于这些功能如何作用于软件项目的生产效率。我的目标可不是写一篇关于语言理论的学术论文，我想要做的是，对每个语言功能都能以事实论证来支持"好"、"坏"、"容易导致问题"的论断。有时候这与理论相关，但我的观点是，理论存在的作用只是使实践更为容易，并使我们原先未曾想过的事情成为可能。理论不是束缚我们的紧身衣，而是催生新事物的孵化器。

人们过于热情地采纳面向对象技术，以至于很多人开始觉得要被这种热情"烤焦了"。我本人的面向对象学习经历始于悉尼大学，当时Jan Hext教授给我们上关于数据抽象的荣誉课程 ，在课程中我们学了Simula。我对这个语言印象很深，不少其他人同样如此，包括Bjarne Stroustrup和Alan Kay。几年后，我开始使用Object Pascal来做几个大型项目，其中的一个项目使我结识了C++。于是，我充满激情地买了Bjarne Stroustrup的The C++ Programming Language第一版。在阅读过程中我略感不安，因为我这个有着几年经验的面向对象实践者，对于书中的部分概念难以理解。似乎这些我熟悉的概念被某种复杂性掩盖了。在那时，C++还是非常简朴的--与当今的C++比确实如此。最初，C++比之Object Pascal并无实际优势可言，那时它不具备多重继承、模板等。我不想脱离实践经验地来评判语言，因为我觉得实践经验应该可以很快澄清一些模糊之处。

也正是在那段时间里，Brain Handerson的推销员将Bertrand Meyer的Object-Oriented Software Construction一书推销给我。我发现这本书读起来很有乐趣，因为它核查了软件工程的真正目标，并给出解决方案。它阐述清楚了不少关于我以前做的项目中正确和错误之处。令我恼火的一件事是，这本书引入了另一种编程语言--Eiffel。我想要的正是这样讲解面向对象的书，但希望是用我懂的一种语言，比如Object Pascal或者较新的C++。我觉得Eiffel在这本书里的角色有点像Knuth在The Art of Computer Programming中使用的MIX汇编语言 。我不喜欢面对又一种编程语言。但是，当我一页一页地翻着这本书，我渐渐发现，Eiffel是如此简洁，根本不会使我分心。虽然我根本没花功夫来学它，但当读完这本书后我觉得我已相当熟悉这种语言了。不仅如此，我还学到了新的高级面向对象技术，比如多重继承、泛型、垃圾收集，而在那个时候，Object Pascal和C++都没有提供这些特性。

当我在Unisys公司工作的时候，真正使用C++的机会来了。一个大项目，UNIX X. 500，是用C++做的。即便那时C++还是比较原始的，没有多重继承、模板之类的特性。编译还是用CFront 。我的同事除C++外很少有面向对象经验，但是对于C++却很有热情：他们认为C++是终结语言，认为如果我不用C++就不能说真正在从事面向对象开发。不久，我就知道了为什么我读Stroustrup的The C++ Programing Language第一版时觉得不自在。我的实践经验并没有澄清我阅读时标出的模糊之处，而是将这种语言的许多缺陷暴露了出来。仅仅两周，我找出的问题的概要就占了整整两页纸篇幅。几个月后，我将这些东西写成一篇报告，将其放到Unisys内部的新闻组上。一些致力于在他们部门推动C++应用的人开始跳出来捍卫C++。但他们这样做的实际结果是，促使我找出了C++更多的缺陷，而那篇文章也变得越来越长。于是，在1992年初，我将其传到了Internet上的新闻组。这份东西再一次地经受了烈火的洗礼，也再一次地让我有了更多的想法。所以我彻底重写了它并作为"第二版"重新发表到Newsnet上面。那已是1992年下半年了。

1992年之后，我认为在这个项目上我已经花了足够多的时间了，我决定转向专攻软件工程。但是，在1996年，我开始试用号称"避免了C++的问题"的Java，于是，正如前文所说，这激励我重新修订我早期对C++的评价，将其与其他语言作比较。这样，这份"C++批判"的第三版 在1996年下半年被我发表在Internet上。

在第三版发表之后，许多人评论说我其实并没有走得很远，C++中还有许多问题。他们讲述给我听一些其他问题，还为我指出了一些其他的研究方向。他们是正确的。我发现了一些新的材料来源，一些我以前从未想过的东西。我开始将这些材料加进去，这导致了第四版的产生。但是，文章已经变得非常长了，当我将其按照书的格式重新编排，我发现已经超过150页了。所以我认定，这份材料适合用来出书。如果你看过前面三个版本，你就会发现这本书保留了不少原来的材料，但将其按照更为合理更适于学习的逻辑顺序重新编排，而且加进了不少新的材料。我希望你喜欢这个结果。所以，它值得购买--或至少值得你从朋友处借来一读。
本书结构贯串全书我们将采用自顶向下的路线带你"游览"面向对象范型（paradigm），逐个审视这些编程语言，关注它们的不同、长处、弱点、问题。

在第1章中我们将探究一些原理和概念，这些原理和概念对于我们评判语言是否适合于任务并得出自己的结论非常重要：因为如果只知道编程语言提供的是什么，而不知道自己应该期待的是什么（即它们提供的应该是什么），我们依然无法得出任何结论。

第2章起步于面向对象语言的制高点，将视野投诸对象、类以及面向对象语言的基本实体。第3章关注模块的概念：在我们的语言中基本实体如何分组，一组类如何打包到一起。第4章研究到了这些实体的内部：功能。

第5章和第6章研究了如何使用这些基本实体来构建较大系统；也就是说，如何使用第5章介绍的继承或者第6章介绍的泛型方法来组合这些实体。

第7章讨论了提供输出及访问控制的功能，研究了如何定义界面，如何阻止对类的实现部分的访问。

第8章研究了对象是如何初始化和销毁的，还涉及了其他一些操作。

第9章讨论强制类型转换，以及它们为何在良好定义的类型系统中是不需要的。

第10章和第11章研究了一些编译时和运行时问题。第12章包括了一些不适合放在其他章节中的杂项内容。

第13章将千头万绪理在一起，并着眼于项目组织、设计及其他因素，以及我们的语言如何提供这些功能。

第14章着眼于一些来自于C而影响C++或者被C++所摒弃的特定问题，以及Java和Eiffel是如何不受这些问题的影响的。
关于C++代码示例
要写出既体现出"可以怎样写"、又体现出"应该怎样写"的C++代码例子可不容易。何谓"可以怎样写"？我的意思是，这样写的代码在绝大多数市场上能找到的编译器上都能够通过编译。那么，何谓"应该怎样写"？那是指按照最新的标准（草案）以及大师们所说的"应该怎样写"的原则来写，这样的代码可能无法被市场上任何编译器通过。只要在书中包含了C++代码例子，作者就无可避免地暴露在"例子不好"的批评火力之下。

这听上去像我给自己找的可怜借口，但是知名的C++作家Al Stevens在近来一次Dr. Dobb's Journal的访谈中这样说：

我们C++作家已经处于两难困境中好长时间了。问题在于语言的快速演化。如果我们按照当前编译器支持的方式来写，那么你的书在写的时候就已经过时了；如果按照标准委员会定义的方式来写，那么很少有编译器可以编译你书中的代码（事实上，目前没有）[Stevens 97]。

Stevens还说：在我书架上的所有C++书籍，包括一些新近出版的，都采用某种代码风格。但是，如果一本全新的书还采用这种代码风格，那么它甚至在走进市场之前就将被标为"老套的"。

他还说：源码清单4是完全兼容（于C++标准）的，但老的C++编译器无法编译。符合标准的编译器（如果有的话）可以编译。权威人物告知Herb和我，我们应该这样教C++程序员编程。所以，源码清单4在原则上正确。

所以，我能肯定，你们毫无疑问可以找到一些批评家说这本书有错，因为示例代码或者不能通过一些编译器的编译，或者不符合标准，或者不符合某些人的观点。所以，我就不为此道歉了--因为这是没有人可以做对的事情。我之所以提供这些示例代码，是因为它们可以帮助阐释我讲述的内容--正如人们所说，一图胜千言。

致谢
大约1996年，我模糊地意识到我发表在Internet上的文章可以扩展为图书项目，但一直没有很重视这个想法，直到Geoff Eldridge表达了这个想法，以及之后对我加以鼓励。Geoff运作着一个网站，传播许多有用的面向对象技术信息。他对我原来关于C++的研究文章的传播也起到了实质性作用。

不久以后，Bertrand Meyer也表达了在（他主编的）面向对象系列丛书中出版本书的兴趣。他对我也鼓励多多，但并未"不正当地"影响本书--虽然他是本书所研究的三种语言之一的作者 。我对于他的编程语言可并不是每次都赞扬有加的J ，能在这本书中自由表达自己的观点并最终出版，我非常感谢他！

John Potter也给了我很大鼓励，并安排我在他领导的设在Macquarie大学的微软研究院对象技术组兼职。他让我做了许多项目并测试别人的项目，从中我获益颇多。当然，我得到的启发也都收入本书与读者分享。在微软研究院的那些讨论很有启发意义，对于我澄清此书中部分内容作用非凡。当然，如果本书有不够确切之处，责任全在我一人。在对象技术组，我和David Clarke在同一办公室。我们进行了许多关于类型的讨论，还分享了许多可笑的幽默。同在对象技术组的David Holmes是Java并行技术的顶尖专家，他为我的初稿提供了许多详尽而有用的建议。原型语言和模式方面的专家James Nobel、三言两语教会我许多关于计算机安全性方面知识的Jon Tidswell、到苏格兰另谋高职的Ryan Shelswell，都为我提供了许多帮助。虽然到了1999年中，对象技术组解散了，但是我确信在未来的千年里你会听到很多关于这些天才的年轻人的故事（如果我们能安然渡过千年虫之难的话） 。

我还要提到的是Jan Hext教授，如我在前文中提到的，我是在他开设于悉尼大学的一门荣誉课程上认识他的。他教我Simula，使我对面向对象技术有了启蒙性的认识--这甚至是在"面向对象"这个词汇广为人知之前。他还给了我一些关于出书注意事项的好建议。Paul Greenfield也在我的持续教育中起了重要作用：他是我在悉尼大学时的教员，也是我后来好几份工作中的同事。从他身上我看到了如何成为具有高瞻远瞩的眼光同时又扎根实践的工程师。Don Gregory也是我的好朋友，他鼓励了我的几次努力奋进，还将本书的早期形式作为一篇论文发表在他的A Series Jounal上面。Owen Reddecliffe则向我证明了高级语言可以同时具有实用性并且极度高效。他用4 000行Basic写了一个类ALGOL语言的编译器，这个事实本身就很有教育意义。

在本书的准备过程中，我的母亲，出乎意料地因心脏手术引起的并发症而去世了。与任何失去至亲长辈的人一样，我希望我能够以更直接的方式来表达对她的感激之情，以及对于许多失去的机会的遗憾。她是爱的典范，对于现代技术被用来增强人类的贪欲和敌意深感痛心。所以，本书献给：

Lois Nellie Joyner

我们缘何关注

我从写作本书中得到的一点经验教训是，一个行业中的专家群体可以更具自我批判精神。医生们似乎很愿意让病人经受他们（指医生）自己不愿接受的治疗过程。许多医疗手段天生具有危险性，而寻找替代手段的研究则进展缓慢。许多医疗手段基于问题发生后的 "再修补"，而非关注病人的整体生活方式并着眼于有效的先期预防。所以，毫不奇怪，有那么多人在寻求其他的医疗手段。问题在于，有太多的人不负责任地鼓吹伪科学的"替代手段"，而且其中不乏试图投机获利的骗子。但是，我们也应该看到某些替代手段背后隐藏着真理，也许它们才是正确的解决之道；可惜的是，行业中的专家群体往往本能地拒绝它们。

不幸的是，计算机行业也存在这样的问题。出于安全性考虑，为了维护某些举足轻重的大公司的利益，许多计算机专家都不愿意探索和鼓励替代手段。如果人类要继续进步，我们应该对研究投入更多，而那些实践者们则应该变得更为心胸宽广。

专家们也被各种规则束缚了手脚，而不幸的是，这些规则常常并不正确。例如，如果某一条规则具有欠缺之处，人们常常制定第二条规则来弥补修正，而非从根本上找出原因解决问题。当然，这并不意味着我们不需要监督者来制止行业中投机者哗众取宠、不劳而获的行为。

目前计算机行业中还有许多人用漏洞百出的论据来为现状辩护，这一事实说明了我们还有很长的路要走。

"为了增进人类总体的幸福，只关注应用科学是不够的。对人类本身及其命运的关注，永远应该成为所有技术努力的主要兴趣所在。为了让我们思维的创造能为全体人类谋求福利而非带来灾祸，我们还应当关注劳动力组织与产品分配这两个重大而未决的问题。当你们沉醉在图表和方程中时，不要忘了这一点。"

--阿尔伯特·爱因斯坦
1931年在加州理工学院的演讲
Ian Joyner是澳大利亚Macquarie大学微软研究院的对象技术组织（Object Technology Group，OTG）的成员。他从1979年起，开始从事面向对象软件的实践和评估工作。1992年，Joyner将自己收集的有关C++缺陷的问题写成一篇名为C++?? A Critique of C++ and Programming and Language Trends of the 1990s的论文发表在新闻组上，引起很大反响，促使作者增补、修改并相继推出了论文第二版和第三版；最终，作者将这篇文章扩充为本书。

鲍志云 是一位计算机科学专业的青年学子，曾以"紫云英"为笔名在《程序员》、《程序春秋》等刊物发表多篇技术文章，并荣膺《程序员》杂志2001年度十佳作者；2002年还和队友一起代表学校参加ACM/ICPC国际大学生程序设计竞赛亚太区比赛并取得佳绩。《对象揭秘：Java、Eiffel和C++》是他的第一部译作。

我可以以亲身经历证明作者所说的话。最初我想使用 C++ 来学习面向对象编程。因为那时候 OOP 已经如此之热使我有一种不马上学习就会惨遭淘汰的危机感。然而学了一段时间，C++ 本身的复杂艰涩并没有给我多大的帮助（那时候我想面向对象本身是很高深的技术，当然要付出更多的努力）。那时候我熟悉 8086 汇编语言、C 语言和 DOS 下几乎所有类型程序的编写方法。我常用的工具是 Turbo C/TASM/Turbo Debugger（90 年代初 M$ 类似的产品和 Borland 相比显然不在同一档次。我们那时候使用的工具比国外要晚 2、3 年以上，所以我在 94、95 年还在使用 Turbo C/Turbo Pascal，那时候国内使用 Windows 的人还很少。可能现在学校里的很多同学仍然是使用 Turbo C/Turbo Pascal 学习编程的）。为了深入学习数据结构我还认真学习了 Pascal（那时候几乎所有数据结构的教材都是用类 Pascal 语言编写的）。Pascal 语言的严谨和简捷深深地打动了我。我听说自从 Turbo Pascal 5.5 以后就可以进行面向对象开发了。我买了一套 Borland 的 Turbo Pascal 用户手册，决定使用 Object Pascal 学习面向对象编程。出乎我的意料，学习 Object Pascal 的感受与学习 C++ 完全不同。我很快就掌握了面向对象编程的大多数基本概念，那种愉快的心情是无法用语言描述的。
（Turbo Pascal 绝对是一个伟大的产品。我现在还保存着那时候的很多开发工具，也许将来有一天能开一个博物馆。早期的很多程序都是使用 Turbo Pascal 开发的，包括很多设备驱动程序。比如 Sound Blaster 16 的驱动和 SDK 都是使用 Turbo Pascal 开发的。Object Pascal 进一步发展到了今天的 Delphi/Kylix。VCL 是用 Object Pascal 编写的，C++ Builder 中的很多控件都是直接从 Delphi 中拿来的。）
在熟悉了 Object Pascal 之后我才开始认真学习 C++，这时候学习就不是很困难了。但是我仍然常常为 C++ 一些莫名其妙的复杂之处所困扰，包括多重继承、操作符重载、输入/输出流等等。那时候还没有 template 和 STL，因此我并没有深入学习过 GP。
我的感受是 C++ 绝对不是一种学习面向对象编程的最佳语言。学习面向对象最好的方法是先学习一种象 Object Pascal 或 Java 这样的语言。掌握了面向对象的精髓之后再学习 C++（那时候可能已经没有多大必要了）。然后在 C++ 中尽量模仿 Object Pascal 或 Java 的开发方法，比如使用抽象类和纯虚函数模拟 Java 的接口。而对于 C++ 中与面向对象关系不大的一些独有特性尽量少用或者不用（我认为这些都不过是些奇技淫巧，这种看法可能会招来一些 C++ Fans 的围攻）。

凡欲买书者，大多会事先问自己：我为何要购买这本书；我将如何阅读这本书？
    就本书而言，译者对第一个问题的答案是：如果你在编程语言的海洋中遨游，因C++强大声势的引力而偏离了航向，那么本书是修正你航向的灯塔；如果你在C++的世界中浸淫已久，那么本书给了你恰当的对照背景，使你不致走向"只见树木，不见森林"的危险边缘；如果你是一位编程实践者，对某种主流语言的各种语言构造都达到了熟练运用的地步，那么本书是你在"知其然"之后增加学养从而达到"知其所以然"境界的良师益友。这里"学养"是指编程语言、软件开发、面向对象技术和泛型技术的内在理论。


另外，购买本书还有一种可能的理由：如果你是C++程序设计者，想要获得绕开语言中的"traps and pitfalls"的能力，那么本书对C++进行批判时所举证的语言构造也正是你应当注意的构造；而书中列举的作为批判对象的示例代码可能也正是你应当尝试着去学习使用的代码。

对出版者而言，本书正好弥补了一个市场间隙--关于主流语言之运用的著作、关于面向对象技术和泛型技术的著作以及程序设计语言理论著作这三者之间的间隙。这也就意味着如果读者没有时间或者没有兴趣面面俱到地阅读前三类著作，那么阅读本书可以获得事半功倍的效果。

具体而言，可能许多读者已经阅读过较多的编程语言著作。对于这些读者来说，因为"边际效益递减"，所以一般的编程著作可能已无法引起兴趣；而阅读很厚的语言理论专著或者面向对象技术专著又有点划不来。那么本书提供了一个"价廉物美"的选择--"价廉"主要是指节省了你的时间成本：读这样一本薄薄的著作相信不会占用你太多的宝贵时间；但是带给你的收益却是实实在在的（故曰"物美"）。本书中不多见于其余编程语言著作但你可能感兴趣的主题包括：契约式设计（Design by Contract）1，泛型理论，类型理论，Simula、Java、Eiffel、C++各自对并行程序设计（主要指多线程）的支持方案，垃圾收集，签名变化（不变、协变、抗变）理论等。

关于本书的第二个问题，答案则因人而异。本书各章相对独立，因此对大部分章节都可单独进行专题阅读。其中第1章给出了本书批判以及立论的出发点，而且这一章不是很长，因此建议每位读者都阅读，以免读到后面对自己所钟爱的语言的"莫名指责"时有焚书的冲动。有些读者可能比较关注面向对象世界中的特定技术，并想要了解几种典型现代语言对这些技术的实现，那么可以在阅读第1章之后选择阅读各章中涉及该语言的小节。只关注理论的读者则不妨跳过关于编程语言实现细节的小节。

另外，译者相信，多数读者对C++和Java都应早有耳闻或者较为熟悉，但Eiffel可能还是个相对陌生的名字。译者认为，语言语法的不同并不重要，背后的理念才是最重要的。因此这里先对Eiffel的设计理念作一简介。

Eiffel的设计者认为，用于程序设计的"语言"不应该太多，从底层的汇编到中层的C++到高层（设计层）的UML、CORBA IDL等。各层语言之间会有"semantic gap"（语义间隙），而这些间隙会导致理解上的歧义，会带来各种bug，会造成沟通上的困难，从而增加了整个软件系统的开发和维护成本。事实上Eiffel之父Betrand Meyer并不愿意人们将Eiffel称作编程语言，他觉得Eiffel应该是一种可以支持从设计到编码到修改的全过程的语言。

Eiffel的设计者还认为，麻烦的事情应该让计算机自己去做，或者由语言和编译器设计者代劳，而呈现在程序员面前的应当是一种良好而一致定义、面向问题、干净利落的说明性语言。

本书作者的观点同Eiffel设计者的理念接近。因此才会对Eiffel的设计赞誉有加。如果你依然不清楚本书的主要内容和定位，那么我就用另一本书--The Design and Evolution of C++（D&E）来同本书（OUE）对照一下：两本书都是阐述语言背后的理念，但D&E更重历史，娓娓道来，而OUE则更重理论，旁征博引而雄辩；D&E主要讲C++为何如此设计，这样设计有多么正确，而OUE则主要从理论出发，讲C++的一些设计有多么不合理，并给出其余语言的例子来佐证。事实上，OUE的许多观点都与D&E针锋相对。
观点的碰撞，部分源于作者经历的不同。OUE的作者Ian Joyner是面向对象技术领域的大师，在微软研究院对象技术组工作，曾参与制定ODP（Open Distributed Processing）的ISO标准。Ian Joyner有很深的理论造诣，而他的C++经历主要来自之前在Unisys公司参与的项目，这一经历可并不让人愉快。相反，D&E的作者、C++之父Bjarne Stroustrup则是因为参与的项目所采用的语言不能让他满意，从而开发了一种新的语言--C++。同样缘自不满，产物却迥异：Ian Joyner带来了一篇在互联网上广为流传的论文（本书的前身）以及这部著作，Bjarne Stroustrup则带来了一种影响深远的语言。其实Ian Joyner也写了一个Eiffel编译器，但产生的影响同C++不能相提并论。他的这部著作倒是影响甚广。

最后，译者希望，自己的努力对这本著作的影响力起到了正面的推动作用，希望本书能对读者有所帮助，希望阅读本书能给读者带来乐趣。如果您觉得从本书获益匪浅，那是Ian的功劳；如果您有什么理解上的障碍，那多半是因为我在将Ian的思想转化成我们熟悉的文字时出了"bug"，请您来E-mail指出。借用侯捷老师一句话：批评的、赞美的、指正的言语，皆请发至我信箱： zmelody@sohu.com 。


鲍志云(笔名紫云英)
2003年1月于  苏州