《Thinking in Java》中文版第一章对象简介.pdf_大学文库

致读者我从2002年7月开始翻译这本书,当时还是第二版。但是翻完前言和介绍部分后, chinapub就登出广告,说要出版侯捷的译本。于是我中止了翻译,等着侯先生的作品。我是第一时间买的这本书,但是我失望了。比起第一版,我终于能看懂这本书了,但是相比我的预期,它还是差一点。所以当 Bruce eckel在他的网站上公开本书的第三版的时候,我决定把它翻译出来。说说容易,做做难。一本1000多页的书不是那么容易翻的。期间我也曾打过退堂鼓,但最终还是全部翻译出来了。从今年的两月初起,到7月底,我几乎放弃了所有的业余时间,全身心地投入本书的翻译之中。应该说,这项工作的难度超出了我的想像。首先,读一本书和翻译一本书完全是两码事。英语与中文是两种不同的语言用英语说得很畅的句子,翻成中文之后就完全破了相。有时我得花好几分钟, 用中文重述一句我能用几秒钟读懂的句子。更何况作为读者,一两句话没搞懂,并不影响你理解整本书,但对译者来说,这就不一样了其次,这是一本讲英语的人写给讲英语的人的书,所以同很多要照顾非英语读者的技术文档不同,它在用词,句式方面非常随意。英语读者会很欣赏这点,但是对外国读者来说,这就是负担了。再有, Bruce eckel这样的大牛人,写了1000多页,如果都让你读懂,他岂不是太没面子?所以,书里还有一些很有“禅意”的句子。比如那句著名的“The genesis of the computer revolution was in a machine. The genesis of our programming languages thus tends to look like that machine.”我就一直没吃准该怎么翻译。我想大概没人能吃准,说不定 Bruce要的就是这个效果这是一本公认的名著,作者在技术上的造诣无可挑剔。而作为译者,我的编程能力差了很多。再加上上面讲的这些原因,使得我不得不格外的谨慎。当我重读初稿的时候,我发现需要修改的地方实在太多了。因此,我不能现在就公开全部译稿,我只能公开已经修改过的部分。不过这不是最终的版本,我还会继续修订的。本来,我准备到10月份,等我修改完前7章之后再公开。但是,我发现我又有点要放弃了,因此我决定给自己一点压力,现在就公开。以后,我将修改完章就公开一章,请关注www.wgqgh.com/shags/tii.html 如果你觉得好,请给告诉我,你的鼓励是我工作的动力;如果你觉得不好,那就更应该告诉我了,我会参考你的意见作修改的。我希望能通过这种方法,译出一本配得上原著的书。 2003年9月8日第1页共34页

1:对象简介我们剖析事物的本质,从中形成概念,并根据需要赋予它重要性。这切很大程度上是源于,我们所使用的语言已经在其形式中包含了一套为它的使用者所完全接受的规范,而我们正属于接受这一规范的那群人.如果我们拒不接受语言在数据的组织与分类方面的原则的话,那我们根本就没法说话。” Benjamin Lee Whorf(1897-1941) 计算机革命的推动力在于机器。于是机器的发展也左右了编程语言发展。然而真正被用作延伸智力的工具的计算机(就像 Steve jobs喜欢说的, “思想的自行车”)并不很多,它们更多的是被用来表达思想。所以结果就是,它们看上去已经不那么像机器了,而更像我们思想的一部分。就像文字,绘画,雕塑,动画以及电影一样,它已经成为一种新的媒体。而面向对象的编程( object- oriented programming缩写是OOP)正是这运动的一部分本章会向你介绍OOP的基本概念和开发的方法。本章,以及本书都假设你有过程语言的编程经验,虽然不一定是C的。如果你决定在继续本书之前,要在编程和C的语法上作更为充分的准备,你可以去看看本书封底所附的,名为 Foundations for Java的练习CD。本章是一个背景介绍和补充材料。很多读者会觉得,在没理解大背景之前就去编写面向对象的程序,会有点不舒服。因此这里会对很多概念做个介绍,并且让你对OOP的概况有个清楚的了解。然而,有些人会认为在见到具体的工作机制之前没必要了解整个大背景;这些人在还没有看到代码之前就会被搞昏的。如果你属于后者,希望尽快进入这个语言的细节,没关系,跳过这章就是了——跳过这章不会妨碍你写程序或者学语言。但是最终你还是要回来补课的,因为只有这样你才会理解为什么对象很重要而且该如何把它们用到设计中去抽象的过程所有的编程语言都提供抽象。甚至可以这么说,你能解决的问题的复杂程度直接与抽象的种类与质量相关。我所说的“种类”是指,“你到底抽象了些什么”。汇编语言是对计算机的抽象,随后许多所谓的“命令”语 (诸如 FORTRAN, BASIC和C)是对汇编语言的抽象。这些语言较汇编语言有了巨大的进步,但这仍然是一种初级的抽象,仍然要求你从计算机的角度,而不是从待解决的问题的角度来思考。程序员必须在机器模型(在解决空间”,也就是你要对那个问题建模的地方,比如在计算机上)与待解决的问题的模型(在“问题空间”,也就是有问题要解决的地方)之间建立关联。处理这种映射所带来的压力,以及编程语言对此无能为力的现第2页共34页

实,造成了程序难写以及维护代价高昂的后果。此外它还带来一个副产品,就是所谓的“编程方法”的行业。取代对机器建模的另一个途径是对你要解决的问题建模。早期语言,诸如 LISP和APL选择了“以某种特殊的视角来观察世界”的方法(分别是 “归根到底,所有问题都是列表”或“所有问题都是算法”)。 PROLOG 则将所有问题都转换成一系列决策。用这类语言编程,成了在约束条件下的编程,而编程也仅限于操控图像符号。(后来证明这种做法的局限性太大了。)它们的设计是针对某些很特殊的问题的。对于那些问题,这些方法都干得不错,但是一旦步出这一领域,它们就显得太滑稽了。面向对象的方法则更进了一步,它为程序员提供了能在问题空间表述各种元素的工具。这种表述是非常通用的,这样程序员就不会被限制在某类特殊问题上了。我们将问题空间的元素同它在解决空间的表述称为“对象”。(此外还需要一些在问题空间并无对照的对象。)这一思想的要点是,通过往程序里面添加新的对象,可以让它适用于问题的各种变例。于是当你阅读代码的时候,它也在向你讲述它要解决的问题。这比我们曾经见过的语言抽象更为灵活也更为强大。2由此OOP允许你以问题的角度,而不是以要解决问题的计算机的角度来描述问题。不过它与计算机还是有联系:每个对象看上去都有点像计算机—一它有状态,有可以让你来执行的操作。但看上去这种对真实世界的模拟还不算太糟——在真实世界中对象也都有自己的特点和行为。 Alan Kay总结了 Smalltalk的五项基本特征。这是最早获得成功的面向对象的编程语言,也是Java所依赖的基础之一。这些特征代表了纯的面向对象的编程方法 1.万物皆对象。将对象想成一种特殊的变量;它存储数据,而且还可以让你“提要求”,命令它进行某些操作。从理论上讲,你可以把所有待解决的问题中的概念性组件(狗,建筑,服务等)都表示成程序里的对象。 2.程序就是一组相互之间传递消息,告诉对方该干些什么的对象。你只要向那个对象“发一个消息”,就能向它提出要求。更确切的说,你可以这样认为,消息是调用专属某个对象的方法的请求。 3.每个对象都利用别的对象来组建它自己的记忆。换言之,你通过将已有的对象打成一个包,来创建新的对象。由此,你可以将程序的复杂性, 隐藏在对象的简单性之下。 4.对象都有类型。说这句话的意思是,任何对象都是某个类的实例 ( instance of a class),而这里的“类( class)”就是“类型type)”的意思。用以区分类的最突出的特点就是“你能传给它什么消息?” 5.所有属于同一类型的对象能接受相同的消息。以后你就会知道,实际上这是“定义”而不是特点。一个“ circle”型的对象也是一个“ shape”型的对象,所以可以保证 circle能接受 shape的消息。也就是说,你写给 shape的代码能自动交由任何符合 shape描述的东西处理。这种互换性 ( substitutability)是OOP最强大的功能之第3页共34页

Booch还给对象下了个更为简洁的定义对象有状态,行为和标识。这就是说,对象可以有内部数据(这给了它状态),有方法(因而产生了行为),以及每个对象都能同其它对象区分开来——具体而言,每个对象在内存里都有唯一的地址。3 对象有接口或许亚里士多德是第一个认真研究类型(type)这个概念的人;他提到过 “鱼类和鸟类”这种概念。对象,虽然都是独一无二的,但同时也是某种有着相同特征和行为的对象的类的一员。这个概念直接以 class关键词的形式为Smua-67—第一种面向对象的语言所采纳。而 class也为程序引入了一种全新的类型。 Simula,就像它的名字所说的,是为了开发诸如经典的“银行出纳问题”而创建的。在这个问题中,你有很多出纳员、客户、帐户、交易以及钱——总之,很多“对象”。那些除了程序执行时状态会有所不同,其它都完全相同的对象,会被集中起来,统称为“对象的类( classes of objects)”。由此得出了 class关键词。在面向对象的编程中,创建抽象的数据类型( class)是一项基本概念。抽象数据类型的工作方式同内置数据类型的几乎没什么不同:你可以创建这个类型的变量(在OOP的术语中,这被称为对象 object或实例 instance),然后操纵这些变量(称为送消息 sending messages或请求 request,你传给对象一个消息,由它来决定该作些什么。)每个类的每个成员(元素 element都有某些共性: 每个帐户都有余额,某个出纳都能受理存款,等等。同时,每个成员还都有自己的状态。每个帐户的余额是不一样的,每个出纳都有自己的名字等等。因此,出纳、客户、帐户、交易等等,它们每个都在计算机程序中代表一个唯一的实体。这个实体便是对象,而每个对象都属于某个类,而这个类会定义它的特征与行为。因此,虽然面向对象的编程就是创建一些新的数据类型,但几乎所有的 OOP语言都选择“cass”这个关键词。所以,当你看到“type”的时候,应该想到它就是“ class”,反之亦然由于类描述的是一组具有相同特征(数据元素)和行为(功能)的对象,所以类实际上是一种数据类型。因为,就拿浮点数举例,它也有它自己的特征和行为。类同数据类型的区别在于,类是程序员为解决特定问题而定做的,而数据类型是为了表示机器的存储单元而设计的,它是现成的,是程序员无可奈何时的选择。你可以根据需要添加新的数据类型,并以此来扩充编程语言。编程系统欢迎这些新的类,它会在管理和类型检査方面给予这些类与内置类完全相同的待遇。第4页共34页

面向对象的方法并不限于创建模拟场景。不论你承认与否,任何程序都在模拟你所设计的系统。用了OP技术,你就能很容易地将一大堆问题简化成一个简单的解决方案。旦创建了类,你就能创建任意多的那个类的对象,然后把它们当作待解决的问题中的元素来进行操控。实际上,面向对象的编程的挑战之一就是,如何在问题空间的元素与解决空间的对象之间建立一种一对一的映射但是怎样让那些对象来为你干活呢?必需要有办法向对象发请求,这样它才能工作。比如完成一次交易,在屏幕上画些东西或者按一下开关之类的。而且每个对象只能满足某些请求。你能向对象发送的请求是由其接口 ( interface)所定义的,而决定接口的则是对象的类型。可以用电灯泡来作一个简单的例子 Type Name Interfa bri gh tend di mo Light lt new Light () 1t.on(); 接口只管你能向这个对象发什么请求。还必须要有能满足这一请求的代码。而这些代码,以及隐藏着的数据,组成了实现(imp/ ementation) 从过程编程的角度来讲,事情没那么复杂。类中的方法都是与各种请求相关联的,因此当你向这个对象提出请求的时候,就会调用这个方法。这个过程通常被称为,你向一个对象“传了一个消息(提了个请求)”,而这个对象会决定该如何处置这个消息(执行代码)。这里,这个类型/类的名字是 Light,而这个具体的 Light对象的名字是 t。你向 Light对象提出的请求有开灯,关灯,让它更亮一点或是暗点。通过定义 Light类型的“ reference”(It),和用new请求一个新对象,你创建了一个 Light对象。发送消息的时候,你要用点号 (dot/ period)将对象的名字和那个消息连起来。如果编程的时候用到的都是已有的类,那么这点知识已经够用了上面的图表遵循了 Unified Modeling Language(UML)的格式。每个类都由一个方框来表示,这个类的名字写在方框的顶部,中间是你要关心的第5页共34页

数据元素,而方法( method,指属于这个对象的函数。它接受你传给这个对象的消息)则列在方框的底部。通常UML的设计图只会显示类的名字以及 public方法,所以中间部分是不显示的。如果你只对类的名字感兴趣,那么最下面的那部分也可以不显示。对象会提供服务当你开发一个程序或者分析一个程序的设计时,理解对象的最佳的方式是把它们当作“服务的提供者”。程序本身会为用户提供服务,而它通过使用其它对象所提供的服务来完成这个工作。你的任务是制作(或者在更理想的情况下,从现有的代码厍中找出)一组能为解决问题提供最佳服务的对象这么做的第一步是问“如果我可以像变魔术那样把东西从帽子里拿出来, 我该拿出些什么东西,哪些对象能立即帮我解决问题?”举例来说,假设你要创建一个簿记程序。可能你会想应该有一些保存预设的输入界面的对象,一组进行簿记计算的对象,以及一个能在各种打印机上打印支票和发票的对象。有些对象或许已经有了,但是那些还没有的应该是什么样的呢?它们应该提供哪种服务,还有它们要完成任务的话,又该用哪些对象呢?如果你不断分析下去,最终你会发现,不是“那个对象写起来很容易”就是“那个对象已经有了。”这是将问题分解成一组对象的一个合理的方法将对象视作服务的提供者还有一个额外的优点:能提高对象的内聚性 ( cohesion)。内聚性高是高质量的软件设计一个基本要求:就是说软件的各种组件(比如对象,也可以是方法或类库)应该能很好的“组装在起”。设计对象时常犯的一个错误就是,往对象里塞了太多的功能。举例来说,设计支票打印模块的时候,你也许会决定设计一个能通晓所有排格式和打印工作细节的对象。很快你就会发现这个任务太艰巨了,或许应该用三个或是更多对象来完成这个工作。第一个对象应该是支票格式的目录册,通过査询这个目录册可以获得该如何打印支票的信息。第二个对象, 或是一组对象,应该是能分辨各种打印机的通用的打印接口(但是对簿记,它一窍不通——这个模块应该买来而不是自己写)。以及使用上述两个对象所提供的服务的,能最终完成任务的第三个对象。由此每个对象都提供一组互补的功能。在一个良好的面向对象的设计中,每个对象都应该只作一件事,并且作好一件事,而不是去作太多的事情。就像这里看到的,这样不仅能发现哪些对象应该买(打印机接口对象),而且能设计出今后能复用的对象(支票格式的目录册) 将对象视作服务的提供者还是一种很了不起的简化工具。它不仅在设计过程中有用,而且还能帮助别人理解你的代码或者复用这个对象——如果他们认同这个对象所提供的服务的话。将对象视作服务的提供者能使对象更容易地被用于设计。第6页共34页

隐藏实现将程序员分成类的创建者(c| ass creator那些创建新的数据类型的人)和客户程序员( client programmer那些使用这些类编程的人)能帮助我们更好地理解这个问题。客户程序员的目的是收集各种类,以便能快速开发应用程序。而类的创建者的目的是创建一些这样的类,它们只透露一些客户程序员必须知道的东西,其它部分则被完全隐藏了。为什么?因为隐藏之后,客户程序员就不能访问了,也就是说类的创建者们可以根据需要修改隐藏部分而不用担心会对其他人造成影响。通常隐藏起来的都是这个类最脆弱的,很容易被粗心大意或不知情的客户程序员给弄坏的内脏部分,所以把实现隐藏起来能减少程序的bug 隐藏实现,这一概念的重要性无论如何强调都不会过分。无论是那种关系,有一个为各方都尊重的边界是非常重要的。创建一个类库之后,你就与客户程序员建立了某种关系。他们也是程序员,他们用你的类库来组装一个应用程序,也可能是一个更大的类库。如果所有人都能看到类的所有成员,那么客户程序员就能对这个类作任何事,因此也谈不上什么强制性的规则了。尽管你真的不想让客户程序员直接操控类中的某些成员,但是如果没有访问控制的话,你也没办法禁止他去这么做。这个类只能赤裸裸地面对整个世界。所以要控制访问权限的首要原因就是,禁止那些客户程序员去碰他们不该动的东西——就是那些数据类型内部运作所必须的东西。只允许他们接触解决问题所必需的接口。实际上这也是提供给用户的一种服务,因为由此他们能很方便的看出哪些东西对他们很重要,哪些跟他们没关系第二个原因是允许类库设计人员能在不打搅客户程序员的情况下修改类的内部工作方式。比如,刚开始设计这个类的时候时,为了降低开发难度, 你用了一种很简单的方法,但随后你发觉应该重写这段代码,让跑得快些。如果这个类的接口与实现分得很清楚,并且保护得很好,那么做起来就会很方便。 Java用了三个明确的关键词来设置类中的边界: public, private,和 protected。它们的用法和意思都相当明了。这些访问控制符表示谁能使用由它定义的东西。 public表示后面跟着的东西谁都能用。而 private 关键词则表示,除非是类的创建者用这个类的方法进行访问,否则没人能访问到这个元素。 private是竖在你与客户程序员之间的一堵墙。那些要访问 private成员的人,会在编译的时候得到一个错误。 protected关键词很像 private,它们的区别在于,继承类能够访问 protected成员,但是不能访问 private成员。继承问题过一会再介绍 Java还有个“缺省”的访问权限,如果你没用上面三个的话,那就是指它了。通常把它称为 package访问权限。因为同属这个 package的类第7页共34页

可以访问这个 package中其它类的“缺省权限”的成员,但是出了这个 package,它们就都是 private的了。复用实现类创建完成并且测试通过之后,它就应该能(很好地)表示一段有用的代码。但实际上代码复用并不像我们希望的那样容易;要设计一个复用性良好的对象,需要经验和远见。代码复用是OOP语言最显著的优点之复用代码最简单的方式是直接用这个类来创建对象,但是你也可以将那个类的对象放到一个新的类中。我们把它称为“创建一个成员对象”。为了能让那个新的类提供你所设计的功能,它可以由任意多个,任意类型的对象,以任意形式组合在一起。由于你是用已有的类来合成新的类,因此这一概念被称为合成( composition,如果这个对象是动态合成的,通常把它称为聚合 aggregation)。通常将合成称为“有(has-a)”关系,就像轿车有引擎 C Engine (这个讲解轿车的UML关系图,用实心菱形表示合成关系。通常如果要让我表示这个关系的话会更简单:就是一根直线,没有菱形。l) 合成具有极大的灵活性。新类里面的成员对象通常都是 private的,因此使用这些类的客户程序员们是无法访问这些对象的。这点能让你在不影响已有的客户代码的前提下,修改这些类。你还可以在运行时修改这些成员对象,并以此动态地改变程序地运行。下面要讲的继承就没有这种灵活性,如果你用继承创建一个类,编译器肯定会加上某些编译时的限制的由于继承在OoP中是如此重要,因此会被反复强调,以至于新手们会认为,应该尽量使用继承。其实一味的使用继承会导致很奇怪也很复杂的设计。相反,在创建新类的时候,你应该优先考虑使用合成,这么做会更简单也更灵活。如果这么做的话,整个设计也会变得更加井井有条。等你有了一点经验之后,你就会自然而然的知道继承应该用在哪里了继承:复用接口对象这个概念本身就是一件很有力的工具。它能让你依照概念把数据与功能结合在一起,这样你就不用站在运行程序的计算机的角度上,而是站在解决问题的角度上来写代码了。这个概念作为程序的基本单位,在编程语言中用 class这个关键词表示。第8页共34页

然而,要是我们费尽心机编写了一个类之后,又不得不再写去一个功能类似的全新的类的话,那就很惨了。要是能将已有的类克隆一份,然后在克隆的类上修修补补,那就好了。而这正是继承( inheritance)的功效。只是区别在于,如果原先那个类(称为基类 base class,父类 parent cass和超类 superclass)作过了修改,那么这个“克隆”(称为衍生类,派生类 derived class或者继承类 in herited class或者子类 subclass, child class)也会随之发生变化。 Base Derived (在UML关系图中,箭头从派生类指向基类。你会发现,通常会有不止个派生类。) 类不仅仅在描述一组施加在对象之上的限制;它还会同其它类发生关系。两个类可以有一些共通的特征和行为,可能其中有一个比另一个特征更多,能处理的消息也更多(或者处理的方式不同)。通过基类和派生类的概念,继承表达了这种相似性。基类保存的是所有继承自它的类的共有特征和行为。创建基类是为了表达,你对系统中某些对象的核心思想的理解而衍生类则是从基类派生出来的,它所表达的是各种实现这个核心思想的方式。举例来说,有一个对垃圾分类的垃圾回收机。基类是“垃圾( trash)”, 每件垃圾都有重量,价值等等,而且可以切碎,融化或者分解。由它派生出的一些具体的垃圾品种会有一些额外的特征(瓶子有颜色)或是行为( 罐可以压缩,铁罐可以磁化)。此外有些行为会不同(纸张的价值由它的品种和状况决定)。通过继承,你能用类构建一个表述你要解决的这个问题的类系( type hierarchy)。第二个例子是经典的“ shape”案例。或许它能用于计算机辅助设计系统或是用来模拟游戏场景。基类是“ shape”,每种形状都有大小,颜色, 位置等属性。从它那里继承下来的具体的形状——圆,矩形,三角形等- —都有额外的特征和行为。比如某些形状可以翻转。有些行为会不同,比如计算面积的方法。整个类系体现了各种形状之间的相同和不同点。第9页共34页

Shape draw erase() moveD getcoloro setcol oro Circle Square Triangle 将描述问题之用的术语用于解决问题也是大有裨益的,因为这样你就不再需要那些在讲述问题和解决方案之间的中间模型了。对于对象,类层次结构是最主要的模型,由此你从用文字描述真实世界中的系统进到了用代码描述这个系统。实际上,大家在用OOP设计时会遇到的难题之一是,它从头到尾太简单了。习惯于用复杂方法解决问题的人可能会一开始就被这种简单给难住了。当你继承了一个类时,你也创建了一个新的类。这个新的类不仅包含了已有类的所有成员(尽管 private成员已经隐藏起来了,是不能访问的), 更重要的是它复制了基类的接口。于是所有能够传给基类的消息也都可以传给派生类。由于我们根据能它能接受什么消息来判断这是什么类,因此这就意味着派生类“和基类是属于同一类型的”。在上面的例子里,“圆也是一种形状”。这种由继承而产生的类的相等性是一扇能让你理解 OoP意义的门。既然基类和派生类具有相同的基本接口,那么这个接口的背后就必须跟着实现。也就是当对象收到某个消息的时候,它必须能执行一些代码。如果你只是继承了一个类,其他什么都不做,那么基类里的方法会直接带进派生类。也就是说派生类的对象不但与基类的对象的类型相同而且行为也样。这可没什么吸引力你有两种办法来区分新的派生出来的类和那个原来的基类。第一种方法很简单:直接往派生类里加新的方法。这些新的方法不属于基类的接口。也就是说由于基类不能完成所有的工作,你必须加上更多方法。这种简单原始的继承方法常常是解决问题的完美方案。然而你还得仔细看看基类是不是也需要这些方法。对于OoP的设计,这种反复发现的过程是很常见的第10页共34页

《Thinking in Java》中文版 第一章 对象简介

《Thinking in Java》中文版第一章对象简介