当前位置：和泉文库 > 计算机 > 浏览文档

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

我们剖析事物的本质,从中形成概念,并根据需要赋予它重要性。这切很大程度上是源于,我们所使用的语言已经在其形式中包含了一套为它的使用者所完全接受的规范,而我们正属于接受这一规范的那群人.如果我们拒不接受语言在数据的组织与分类方面的原则的话,那我们根本就没法说话。” Benjamin Lee Whorf(1897-1941) 计算机革命的推动力在于机器。于是机器的发展也左右了编程语言发展。

文件格式：PDF，文件大小：505.97KB，售价：8.31元

共34页，可试读12页，点击往前阅读 ↑↑

文档详细内容（约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页

点击进入文档下载页（PDF格式）

共34页，可试读12页，点击继续阅读 ↓↓

您可能感兴趣的文档

点击购买下载（PDF）

下载及服务说明

购买前请先查看本文档预览页，确认内容后再进行支付；
如遇文件无法下载、无法访问或其它任何问题，可发送电子邮件反馈，核实后将进行文件补发或退款等其它相关操作；
邮箱：

文档浏览记录