《OOD启思录》—第2章2.5节 抽象类

2.5 抽象类
OOD启思录
除了我们已经讨论过的类,还有一种重要的抽象类型是我们需要探讨的。请思考下列问题:你曾经吃过水果吗?你曾经吃过开胃菜吗?你曾经吃过甜点吗?很多人对这3个问题的答案都是“是”。只要你对这3个问题中的任一个回答了“是”,请你接着思考下面的问题:水果尝起来味道如何?一份甜点有多少卡路里的热量?一份开胃菜价格是多少?

我可以说,没有人吃过“水果”。很多人吃过苹果、香蕉或者桔子,但没有人吃过一个3斤重的、红色的就叫做“水果”的东西。类似地,当你坐在餐厅中,服务员走来问你想吃些什么时,你回答“一份开胃菜、一份主菜还有一份甜点”,如果这时服务员就转身走了,你就有麻烦了,因为你喜欢虾,而不喜欢瓜(两种可能的开胃菜)。我们认可,没有“水果”、“开胃菜”或者“甜点”这样的对象,但是这些名词确实表达了有用的信息。如果我拿起一只闹钟对你说:“你觉得我的水果怎么样?”你会认为我疯了;而如果我拿起一只苹果问同样的问题,你就会觉得很正常。“水果”这个称谓表达了有用的信息,虽然你不能创建水果对象。事实上,它是一个类(概念),但不知道如何实例化它这种类型的对象。

不知道如何实例化对象的类称为抽象类(abstract class)。

知道如何实例化对象的类称为具体类(concrete class)。

请留心我们经常使用的术语“抽象数据类型”(ADT)。有的时候,它被用作“类”的同义词,并且不区分抽象类和具体类。

在面向对象范型中,抽象类的一个重要用途是帮助创建继承层次结构。它们表达了类别名称(见图2.10)。我们将在第5章讨论它们的用处。

本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

时间: 2024-09-29 18:24:16

《OOD启思录》—第2章2.5节 抽象类的相关文章

《OOD启思录》—第2章2.1节类和对象导引

第2章 类和对象:面向对象范型的建材OOD启思录2.1 类和对象导引面向对象范型使用类和对象的概念作为基本建筑材料.应用程序的分析.设计.实现模型一致地使用这些概念.通过现实世界中的例子来解释这些概念是最佳方案.如果有一屋子的人,你问:"给你们所需的全部零件,谁能装配出一只闹钟"?最多有一两个人会举手.但如果你问他们"这个房间里谁能够把闹铃设到早上9点",那么我可以放心地和你打赌,大多数人都会举手.大多数人会使用闹钟,但不会装配闹钟,这难道不荒谬吗?对这个问题,你最

《OOD启思录》—第1章1.1节革命家、改革家与面向对象范型

第1章 面向对象编程的动因OOD启思录1.1 革命家.改革家与面向对象范型在学习面向对象范型以及相关知识的过程中,你首先必须知道我们社区中的很多对立观点.每组对立观点意味着两个或者多个阵营,他们对自己的观点一般都具有宗教般的热情.最重要的对立观点之一是革命家与改革家之争.革命家相信,有一群开发者某一天在凌晨3点醒来,并发现以前我们一直都在用错误的方式开发软件.他们相信,他们找到了解决软件危机的方法,并且把这种方法叫做"面向对象编程".或许读者已经猜到,我是属于改革家阵营的. 改革家认为

《OOD启思录》—第2章2.4节动态语义

2.4 动态语义OOD启思录除了固定的数据和行为的描述之外,对象在运行时还随着其数据描述的动态取值具有局部状态(即当时的"快照").类的对象的所有可能状态的集合以及状态间合法的变换称为类的动态语义(dynamic semantics).动态语义允许对象对其生命期的两个不同时候发来的相同消息作出不同的回应.例如,看这个抽象例子: Method junk for the class X if (local state #1) then do something else if (local

《OOD启思录》—第1章1.2节Frederick Brooks观点:非根本复杂性与根本复杂性

1.2 Frederick Brooks观点:非根本复杂性与根本复杂性OOD启思录Frederick Brooks在1987年10月份的IEEE Computer上发表了一篇有趣的文章,标题是Conceptual Essence of Software Engineering or There Is No Silver Bullet [参考文献1].Frederick Brooks是The Mythical Man-Month [参考文献2]的作者.The Mythical Man-Month记

《OOD启思录》—第2章2.2节消息和方法

2.2 消息和方法OOD启思录对象应当被看作机器,机器只为提出恰当请求的人执行公有接口所定义的操作.因为对象独立于使用者,也因为一些实现了面向对象概念的早期语言的语法,术语"发送消息"用于描述执行对象的行为.当消息被发送至对象,它必须判断是否理解该消息.如果理解,那么对象就把消息映射为一个函数调用,并把自身作为隐含的第一个参数传递过去.对解释语言而言,判断是否理解一个消息是在运行时完成的,而编译语言则是在编译时完成的. 对象行为的名称(或者原型)被称作消息(message).许多面向对

《OOD启思录》—第2章2.3节 类耦合与内聚

2.3 类耦合与内聚OOD启思录一些经验原则用于解决类的耦合与内聚问题.我们努力让类更紧密地内聚,并尽量降低类间耦合程度.这和在面向动作范型中试图让函数更紧密地内聚并尽量降低函数间的耦合程度的努力是一致的.函数中的紧密内聚意味着组成函数的所有代码都是紧密相关的.函数间的松耦合意味着当一个函数想要使用另一个函数时,它应当在总是从同一点进入该函数,并从同一点退出.这样,我们就可以得出这样的面向动作的经验原则:"函数应当只有一条返回语句." 在面向对象范型中,我们把松耦合和紧内聚的目标映射到

《OOD启思录》—第1章1.4节迭代模型

1.4 迭代模型OOD启思录软件开发的迭代模型看上去和瀑布模型差不多,区别只在于迭代模型允许开发者沿项目流程往返(见图1.2).如果我们在为系统的某个部分编写代码时发现了一个设计缺陷,我们可以回到设计阶段来分析并改正它.或者,如果我们在测试系统的一部分时发现了新的系统需求,我们可以回到分析阶段来修正这个问题.在面向动作范型中,迭代模型会带来很多问题.面向动作的软件常常会有很多位于数据和行为之间的隐含依赖关系.再同集中控制机制一结合,你就会发现自己处于这样一个境地:如果触动了已经存在的应用程序的部

《OOD启思录》—第2章2.6节角色与类

2.6 角色与类OOD启思录经验原则2.11确保你为之建模的抽象概念是类,而不只是对象扮演的角色. "母亲"或者"父亲"是不是类,还是某个"人"对象所扮演的角色?答案取决于设计者为之建模的领域是什么.如果在给定的领域中,母亲和父亲具有不同的行为,那么或许他们应当被建模为类.如果他们的行为相同,那么他们只是"人"类的对象所扮演的不同角色.例如,我们可以把家庭看作"父亲"类的对象."母亲"类

《OOD启思录》—第1章1.7节优秀设计者阶层

1.7 优秀设计者阶层OOD启思录Brooks在"No Silver Bullet"一文中提到的作为控制根本复杂性方法的最后一个话题是在企业中建立一个优秀软件设计者阶层,让他们从大批初级设计者中选拔接班人.这可以同管理者阶层类比:高级经理位居顶端,并且从大批初级经理中选拔接班人.这触及了软件开发者间"艺术还是科学"这一争论的核心.软件开发能力是后天习得的,还是需要天赋?我不想参加这一争论,但我想做个类比.如果有人拿枪指着我的脑袋逼我在一年内学会弹钢琴(我之前从未学过