C++面向对象编程基础：从对象到抽象数据类型

4星 · 超过85%的资源需积分: 29 141 浏览量更新于2024-07-26 10 收藏 13.93MB PDF 举报

"《思考在C++中文版》是一本探讨面向对象程序设计（Object-Oriented Programming, OOP）原理和技术的专业书籍。作者通过历史背景的介绍，阐述了计算机如何从单纯的机器发展成为具有表达能力的媒介，从而引出了OOP在现代编程中的重要性。本书第一章主要介绍了OOP的基本概念，包括： 1.1 对象：在OOP中，对象被定义为具有特定特性（数据）和行为（功能）的实体。这种概念起源于60年代的Simula-67语言，它最初是为了模拟复杂系统，如银行出纳业务中的各类实体。对象的“类”概念来源于这些相似特性和行为的集合，程序员可以根据实际问题定制自己的数据类型，而非受限于机器存储单元的现有类型。 1.1.1 类与抽象数据类型：类是程序员自定义的数据类型，它们描述了一组具有相同属性和操作的对象。类不仅用于模拟现实世界，还被广泛应用于程序设计中，如Smalltalk，这使得OOP技术在解决复杂问题时展现出强大的抽象能力。抽象数据类型（Abstract Data Type, ADT）是OOP的核心概念，它允许程序员创建类的实例，并通过发送“消息”或执行方法来操作这些实例，实现了灵活性和可重用性。 1.1.2 封装和继承：封装是OOP的另一个关键特性，它隐藏对象的实现细节，只暴露必要的接口给用户，从而保证了代码的模块化和安全性。继承则允许创建新类（子类）基于已有类（父类），继承了父类的属性和行为，进一步扩展了程序的结构和复用性。本章旨在为读者提供OOP的基础，强调了在深入学习C++语言之前理解这些概念的重要性。对于希望直接学习语言内容的读者，虽然可以跳过这一章节，但在后续章节中，这些概念将会起到至关重要的支撑作用。因此，阅读和掌握面向对象的思维方式和设计原则，对于在C++或其他OOP语言中编写高效、可维护的代码至关重要。"

设计发现和对象发现过程类似，因此我们可以在会议过程中将子条目增加到这两个段中。

1.4.5 开发

这是粗设计到编译代码的最初转换，编译代码能被测试，特别是，它将证明或者反证我们

的设计。这不只是一遍处理，而是一系列写和重写的开始，所以，重点是从文档到代码的转换，

该转换用这样一种方法，即通过对代码中的结构或有关文字的改变重新产生文档。这样，在编

码开始后（和不可避免的改变出现后）产生设计文档就变得非常容易了，而设计文档能变成项

目进展的报告工具。

1. 初始翻译

通过在第一层的标题中使用标准段名“对象”和“设计”，我们就能运行我们的工具以突

出这些段，并由它们产生文件头。依据我们所在的主段和正在工作的子段层，我们将完成不同

的工作。最容易的办法可能是让我们的工具或宏把文档分成小块并且相应地在每一小块上工

作。

对于“对象”中的每个第二层段，在段名（类名和它的基类名，如果有的话）中会有足够

的信息用以自动地产生类声明，在这个类名下面的每个第三层子段，段名（成员函数名、参数

表和返回类型）中会有足够的信息用以产生这个成员函数的声明。我们的工具将简单地管理这

些并创建类声明。

为了使问题简单，单个类声明将出现在每个头文件中。命名这些头文件的最好办法，也许

是包括这个文件名，以作为这个类的第二层段名中的标记信息。

编制情节可以更精细。每个子情节可以产生一个独立的函数，由内部 main( )调用，或者就

是main( )中的一段。从一个能完成我们的工作的事情开始，更好的模式可能在以后的反复中形

成。

2. 代码产生

使用自动工具（大部分字处理工具对此是合适的）：

1) 为 “对象”段中描述的每个类产生一个头文件，也就是为每一个类创建一个类声明，

带有公共接口函数和与它们相联系的描述块；对每个类附上在以后很容易分析的专门标号。

2) 为每个子情节产生头文件，并且将它的描述拷贝在文件的开头，作为注释块，接下来跟

随函数声明。

3) 用它的概要标题层标记每个子情节、类和方法，形成加标号的、被注释的标识符：

/ / # [ 1 ]、// #[2]等等。所有产生的文件都有文档注释，放在带有标号的专门标识块中。类名和函

数声明也保留注释标记。这样，转换工具能检查、提取所有信息，并用文档描述语言更好地重

新产生源文档，例如用Rich Text Format(RT F ) 描述语言。

4) 接口和情节在这时应当是可编译的（但不可连接），因此可以做语法检查。这将保证设

计的高层完整性。文档能由当前正在编译的文件重新产生。

5) 在这个阶段，有两件事会发生。如果设计是在早期，那么我们可能需要继续加工处理集

体讨论会的文档（而不是代码）或小组负责的那部分文档。然而，如果设计是完全充足的，那

么我们就可以开始编码。如果在编码阶段增加接口元素，则这些元素必须连同加过标号的注释

一起由程序员加标号，所以重新产生的程序能用新信息产生文档。

如果我们拥有前端编译器，我们确实可以对类和函数自动进行编译，但是它是大作业，并

且这个语言正在演化。使用明确的标号，是相当不安全的，商业浏览工具能用以检验是否所有

的公共函数都已经形成文档了（也就是，它们已加标号了）。

16 C + + 编程思想

下载

1.4.6 重写

这类似于重写电影剧本以完善它，使它更好。在程序设计中，这是重复过程，我们的程序

从好到更好，在第一遍中还没有真正理解的问题变得清楚了。我们的类从在单个项目中使用进

化为可重用的资源。

从工具的观点看，转换该过程略微复杂，我们希望能分解头文件，使我们能重新整理这些

文件使它们成为设计文档，包括在编码过程中已经做过的全部改变。在设计文档中对设计有任

何改变，头文件也必须完全重建，这样就不会丢失为了得到在第一遍反复中编译所需要的头文

件而做的任何工作。因此，我们的工具不仅应当能找出加标号的信息，将它们变成段层和文本

层，而且还应当能发现其他信息，为其他信息加标号和存放其他信息，例如在每个文件开头的

# i n c l u d e。我们应当记住，头文件表达了类设计而我们必须能够由设计文档重新产生头文件。

我们还应当注意文本层注解和讨论，它们最初产生时被转换为加标号的注释，比在设计演

化过程中程序员修改的内容更多。基本上，这些注解和讨论被收集并放在各自的地方，因此设

计文档反映了新的信息。这就允许我们去改变这些信息，并且返还到已产生的头文件中。

对于系统设计（ m a i n ( ) 和任何支持函数），我们也可能想获得整个文件，添加段标识符，

例如A、B、C等等，作为加标号的注释（不用行号，因为行号会改变），并附上段描述（然后

返还m a i n ( )文件，作为加标号的文本）。

我们必须知道什么时候停止，什么时候重复设计。理想的情况是，我们达到了目标功能，

处在完善和增加新功能的过程中，最后期限到来，强迫我们停止并发出我们的版本（记住，软

件是预约业务）。

1.4.7 逻辑

我们会周期性地希望知道项目在什么地方需要重新整理文档。如果是在网上使用自动化工

具，这个过程无关紧要。经常地整集和维护设计文档是项目领导者或管理者的责任，而项目组

或个人只对文档的一小部分负责（也就是他们的代码和注释）。

对于补充功能，例如类图表，可以用第三方工具生成，并自动地添加到文档中。

在任何时候，都可以通过简单地“刷新”文档生成当前的报告。这样可以看到程序各部分

的情况，也支援了项目组，并为最终用户文档提供了直接的更新。这些文档对于使新组员尽快

参加工作也很有价值。

单个文档比由某些分析、设计和实现方法而产生的所有文档更合理。虽然一个较小的文档

缺乏印象，但它是“活的”。相反，例如一个分析文档只是对于项目的特殊阶段有价值，然后

很快变得陈旧了。对于知道将被丢掉的文档，人们很难对它再作更大的努力。

1.5 其他方法

当前有大量的形式化方法（不下 2 0种）可用，由程序员选择

[ 1 ]

。有一些并不完全独立，它

们有共同的思想基础，在某个更高层上，它们都是相同的。在最低层，很多方法都受语言的缺

省表现约束，所以每个方法大概只能满足简单的项目。真正的好处是在较高层上，一个方法可

用于实时硬件控制器，但可能不容易适合档案数据库的设计。

每种方法都有它的啦啦队，在我们对大规模方法采用之前应当更好地懂得它的语言基础，

第1章对象的演化 17

下载

[1] 这些是下书中的综述：Object Analysis and Design:Description of Methods, edited by Andrew T. F.Hutt of Object

Management Group(OMG),john Wiley & Sons, 1994。

以此来认识一个方法是否适合我们的特殊风格，或者我们是否真需要一个方法。下面是对最流

行的三种方法的描述，主要是供参考，不是购买比较。如果读者想了解更多的方法，有许多书

籍可以参考，还有许多学习班可以参加。

1.5.1 Booch

B o o c h方法

[1]

是最早、最基本和最广泛被引用的一个方法。因为它是较早发展的，所以对

各种程序设计问题都有意义。它的焦点是在 O O P 的类、方法和继承的单独性能上，步骤如下：

1. 在抽象的特定层上确定类和对象

这是可预见的一小步。我们用自然语言声明问题和解，并且确定关键特性，例如形成类的

基本名词。如果我们在烟花行业，可能想确定工人、鞭炮、顾客，进而，可能需要确定化学药

剂师、组装者、处理者，业余鞭炮爱好者和专业鞭炮者、购买者和观众。甚至更专门的，能确

定年轻观众、老年观众、少年观众和父母观众。

2. 确定它们的语义

这是在相应的抽象层上定义类。如果我们计划创建一个类，我们应当确定类的相应观众。

例如，如果创建鞭炮类，那么谁将观察它，化学药剂师还是观众？前者想知道在结构中有什么

化学药剂，而后者将对鞭炮爆炸时释放的颜色和形状感兴趣。如果化学药剂师问起一个鞭炮产

生主颜色的化学药剂，最好不要回答“有点冷绿和红”。同样，观众会对鞭炮点火后喷出的只

是化学方程式感到迷惑不解。也许，我们的程序是为了眼前的市场，化学药剂师和观众都会用

它，在这种情况下，鞭炮应当有主题属性和客体属性，并且能以和观察者相应的外观出现。

3. 确定它们之间的关系（CRC 卡片）

定义一个类如何与其他类互相作用。将关于每个类的信息制成表格的常见的方法是使用类，

责任，协作（Class, Responsibility, Collaboration, CRC)卡片。这是一种小卡片（通常是一个索

引卡），在它上面写上这个类的状态变量、它的责任（也就是它发送和接受的消息）和对与它

互相作用的其他类的引用。为什么需要索引卡片？理由是我们应当能在一张小卡片上存放我们

需要知道的关于一个类的所有内容，如果不能满足这点，那么这个类就太复杂了。理想的类应

当能在扫视间被理解，索引卡片不仅实际可行，而且刚好符合大多数人思考问题合理的信息量。

一种不涉及主要技术改革的解决办法对于每个人都可用的（就像本章前面描述的草稿方法中的

文档结构化一样）。

4. 实现类

现在我们知道做什么了，投入精力进行编码。在大多数项目中，编码将影响设计。

5. 反复设计

这样的设计过程给人一种类似著名的程序开发瀑布流方法的感觉。现在对这种方法的看法

是有分歧的。在第一遍查看主要的抽象是否可以将类清晰地分离之后，可能需要重复前三个步

骤。B o o c h写了一个“粗糙旅程完型设计过程”。如果这些类真正反映了这个解的自然语言描

述，那么程序有完型的观点应当是可能的。也许要记住的最重要的事情是，通过缺省

—

实际

上是通过定义，如果修改了一个类，它的超类和子类应当仍然工作。不需要害怕修改，它不会

破坏程序，对结果的任何改变将限制在子类和 /或被改变的这个类的特定协作者中。为了这个

类而对C R C卡片的扫视也许是我们需要检验新版本的唯一线索。

18 C + + 编程思想

下载

[1] 参看Object-Oriented Design with Applications by Grady Booch, Benjamin Cummings, 1991.有关C + +更新的版

本。

1.5.2 责任驱动的设计（RDD）

这个方法

[1]

也用C R C卡片。在这里，正如名称蕴涵，卡片的重点在于责任的授权，而不是

外观。这可由下面例子说明： B o o c h方法可以产生雇员

—

银行雇员

—

银行经理的继承，而

在R D D中，这可能出现经理

—

金融经理

—

银行经理的继承。银行经理的主要责任是经理的

责任，所以这种继承反映了这种关系。

更形式化地说，R D D包含如下内容：

1) 数据或状态：对每个类的数据或状态变量的描述。

2) 池和源：数据池和源的标识；处理或产生数据的类。

3) 观察者或观点：观点或观察者类，用以隔离硬件依赖。

4) 辅助工具或帮助器：辅助工具或帮助器类，例如连接表，它们包含很少的状态信息并

简单地帮助其他类工作。

1.5.3 对象建模技术（OMT）

对象建模技术

[ 2 ]

（O M T ）对过程增加一个或多个复杂层。 B o o c h 方法强调类的功能表现，

简单地定义它们作为自然语言解的轮廓。 R D D 进了一步，强调类的责任超过强调类的表现。

O M T 用详细地绘制图表的方法，不仅描述类，而且还描述系统的各种状态，如下所述：

1) 对象模型，“什么”，对象图表：该对象模型类似于由 B o o c h 方法和R D D 产生的那些模

型；对象的类通过责任相关联。

2) 动态模型，“何时”，状态图表：该动态模型描写了系统的与时间有关的状态。不同的状

态是通过转变相关联的；包含时间有关状态的一个例子是实时传感器，它从外部世界收集数据。

3) 功能模型，“如何”，数据流程表：该功能模型跟踪数据流。它的理论是，在程序的最

低层上，实际的工作是通过使用过程而完成的，因此程序的低层行为最好通过画数据流来理解，

而不是通过画它的对象来理解。

1.6 为向OOP转变而采取的策略

如果我们决定采用O O P ，我们的下一个问题可能是“我如何才能使得管理员、同事、部门、

伙伴开始使用O O P？”想一想，作为独立的程序员，应当如何学习使用新语言和新程序设计。

正如我们以前所做的，首先训练和做例子，再通过一个试验项目得到一个基本的感觉，不要做

太混乱的事情，然后尝试做一个“真实世界”的实际有用的项目。在我们的第一个项目中，我

们通过读、向上司问问题、与朋友切磋等方式，继续我们的训练。基本上，这就是许多作者建

议的从C转到C + +的方法。转变整个公司当然应当采用某个动态的小组，但回忆个人是如何做

这件事的，能在转变的每一步中起到有益的作用。

1.6.1 逐步进入OOP

当向O O P和C + + 转变时，有一些方针要考虑：

1. 训练

第一步是一些形式的培训。记住公司在平常的 C代码上的投资，并且当每个人都在为这些

遗留的东西而为难时，应努力在6到9个月内不使公司完全陷入混乱。对一个小组进行培训，更

第1章对象的演化 19

下载

[1] 参看Designing Object-Oriented Software by Rebecca Wirfs-Brock et al., Prentice Hall, 1990。

[2] 参看Object-Oriented Modeling and Design by James Rumbaugh et al., Prentice Hall,1991。

适宜的情况是，这个小组成员是一些勤奋好学、能很好地在一起工作的人们，当他们学习 C + +

时，能形成他们自己的支持网。

有时建议采用另一种方法，即在整个公司层一起训练，包括为策略管理员而开设的概论课

程，以及为项目建设者而开设的设计课程和编程课程。对于较小的公司或较大公司的部门，用

他们做事情的方法去做基本的改变是非常好的。然而代价较高，所以一些公司可能选择以项目

层训练开始，做飞行员式的项目（可能请一个外面的导师），然后让这个项目组变成公司其他

人的老师。

2. 低风险项目

首先尝试一个低风险项目，并允许出错。一旦我们已经得到了一些经验，我们就将这第一

个小组的成员安插到其他项目组中，或者用这个组的成员作为 O O P的技术支柱。第一个项目可

能不能正确工作，所以该项目在事情的安排上应当不是非常重要的。它应当是简单的、自包含

的和有教学意义的。这意味着它应当包括创建对公司的其他程序员学习 C + + 有意义的类。

3. 来自成功的模型

从草稿开始之前，挑一些好的面向对象设计的例子。很可能有些人已经解决过我们的问题，

如果他们还没有正确地解决它，我们可以应用已经学到的关于封装的知识，来修改存在的设计，

以适合我们自己的需要。这是设计模式

[1]

的一般概念。

4. 使用已存在的类库

转变为C + +的主要经济动机是容易使用以类库形式存在的代码，最短的应用开发周期是除

了m a i n ( )以外不必自己写任何东西。然而，一些新程序员不理解这个，不知道已存在的类库，

或由于对语言的迷恋希望写可能已经存在的类。如果我们努力查找和重用其他人在转变过程中

的早期代码，那么我们在O O P 和C + + 方面将是最优的。

5. 不要用C + +重写已存在的代码

虽然用C + + 编译C代码通常会有（有时是很大的）好处，它能发现老代码中的问题，但是

把时间花在对已存在的功能代码进行 C + + 重写上，通常不是时间的最佳利用。如果代码是为重

用而编写的，会有很大的好处。但是，有可能出现这种情况：在最初的几个项目中，并不能看

到效率如您梦想的一样增长，除非这是新项目。当然，如果项目是从头开始的， C + +和O O P最

好。

1.6.2 管理障碍

对于管理员，他的任务就是为他的小组获得资源，使他的小组克服通往成功路上的障碍。

并且，他应当努力创造高产的和令人愉快的环境，以使得他的小组最大可能完成他所要求的奇

迹。转变到C + +的过程包含有下面的三类障碍，如果不花费何代价，那真是奇怪的。虽然对于

C程序员（也许对于其他过程语言的程序员）小组，可证明选择 C + + 比选择其他O O P 语言代价

低，但这也不是免费的。我们应当认识到，在我们试图动员我们的公司转移到 C + +和着手转移

之前，还有一些障碍。

1. 启动代价

这个代价要比得到 C + + 编译器大得多。如果投资培训（也许为了指导第一个项目），并且

如果选购解决问题的类库，而不是试图自己建立这些类库，那么可以将中长期代价减到最低。

这些都是很花钱的，必须在制定计划时充分考虑。另外，当学习新语言连同程序设计环境时，

20 C + +编程思想

下载

[1] 参看Camma et al., 出处同上。

剩余431页未读，继续阅读

不是合格开发者

粉丝: 1
资源: 9

C++面向对象编程基础：从对象到抽象数据类型

Thinking in C: Foundations for Java & C++

Thinking in C++中文版

Thinking in C 英文版

Thinking+in+C+++简体中文第二版.pdf

Thinking in C++ 中文高清PDF版(part1)

《Thinking in C++》pdf电子版

C++编程思想(Thinking in C++)完美版pdf

Thinking c++ 中文版 （pdf）

深入理解《Thinking in Java》第四版：中文高清PDF

《Thinking in Java》第四版：中文PDF，全面解析Java编程

最新资源

Thinking c++ 中文版（pdf）