C程序设计(自考4737)第10章.pptVIP

第10章 面向对象专题讨论 本章先讨论在实际应用中需要考虑的几个专题： 如何发现对象 如何发现对象的数据成员和成员函数 如何定义数据成员和成员函数 如何发现基类和派生类结构 如何考虑接口继承与实现继承 最后给出一个设计实例。 本章的目的是加深对知识的理解并锻炼解决实际问题的能 力，希望通过本章的学习，能将所学知识正确地运用到实 际中去。 主要内容 10.1 过程抽象和数据抽象 10.2 发现对象并建立对象层 10.3 定义数据成员和成员函数 10.4 如何发现基类和派生类结构 10.5 接口继承与实现继承 10.6设计实例 10.1 过程抽象和数据抽象 抽象(abstraction)是形成概念的必要手段，它是从许多事 物中舍弃个别的、非本质性的特征，抽取共同及本质性的 特征，例如。谈到猫，世上没有任何两只猫是完全相同的 ，但是舍弃了每只猫相互之间的差异，把共同和本质性的 特征抽取出来，就形成了“猫”这个概念。 对于分析而言，抽象原则具有两方面的意义： 尽管问题域中的事物很复杂，但分析员并不需要了解 和描述它们的全部，只需要分析研究其中与系统目标有关 的事物及其本质性特征。对于那些与系统目标无关的特征 和许多具体的细节，即使有所了解，也应该舍弃。 通过舍弃个体事物在细节上的差异，抽取其共同特征 而得到一批事物的抽象概念。OOA中的类就是这样得到 的。 抽象是面向对象方法中使用最为广泛的原则，例如系统中 的对象是对现实世界中事物的抽象；类是对象的抽象；数 据成员是事物静态特征的抽象；成员函数是事物动态特征 的抽象等。 在软件开发领域中，早在面向对象方法出现之前就已经开 始运用抽象的原则，主要是过程抽象和数据抽象。 过程抽象是指任何一个完成确定功能的操作序列，其使用 者都可把它看做一个单一的实体，尽管实际上它可能是由 一系列更低级的操作完成的。运用过程抽象，软件开发者 可以把一个复杂的功能分解为一些子功能；如果子功能仍 然比较复杂，则可以进一步分解。这使得开发者可以在不 同的抽象层次上考虑问题，在较高的层次上思考时可以不 关心较低层次的实现细节，即只注意一个过程完成什么功 能，而不注意它是怎样完成的。过程抽象不是OOA的主 要抽象形式，因为面向对象方法不允许超出对象的界限在 全系统的范围内进行功能的描述。但是过程抽象对于在对 象范围内组织对象的成员函数是很有用的。 数据抽象是根据施加于数据之上的操作来定义数据类型 ，并限定数据的值只能由这些操作来修改和观察。 程序设计语言的类型定义就是抽象原则的运用（如根据整 数集合及该集合所适应的共同四则运算等操作，抽象出整 数类型）。 20世纪70年代后期形成的抽象数据类型理论明确提出把数 据及其操作结合为一个整体并实行信息隐蔽，这是对数据 抽象原则的进一步发展。 10.2 发现对象并建立对象层 软件开发者将被开发的整个业务范围称作“问题域”。可以 按如下步骤考虑发现对象并建立对象层。 1. 将问题域和系统责任作为出发点 问题域和系统责任从不同的角度告诉分析员应该设立哪些对 象，问题域侧重客观存在的事物与系统中对象的映射, 系统 责任侧重于系统责任范围内的每一项职责都应落实到某些对 象来完成。两者有很大部分重合，但又不完全一致。 2. 正确运用抽象原则 OOA使用对象映射问题域中的事物，但并不是对分析员见 到的任何东西都在系统中设立相应的对象。OOA需要正确 地运用抽象原则，即紧紧围绕系统责任这个目标去进行抽象 。 抽象意味着要有所取舍。取舍的准则是看被观察的事物及 其特征是否与当前的目标有关。中国古代“九方皋相马”和“ 庖丁解牛”的故事就含有这种哲理。九方皋应伯乐之荐， 为秦穆公寻得千里马，但在复命时却把马的公、母和颜色 都说错了。穆公对其能力表示怀疑。伯乐回答说：“皋之 所观，天机也：得其精而忘其粗，得其内而忘其外”。把 马牵来一试，果然是一匹千里马。精于相马的高手把主要 精力都集中于跟自己的目标有关的特征上，忽略了与目标 无关的特征。宋国庖丁解牛时则从另一个角度抽象，他的 目标是看牛的皮、肉、筋、骨中哪里有缝隙可以下刀，他 是“目无全牛”。有人对此二事做成一联： 九方皋相马，不分牡、牝、骊、黄，心唯骏马特征； 宋庖丁解牛，只见筋、骨、皮、肉，目无全牛形象。 在OOA中正确地运用抽象原则，首先要舍弃那些与系 统责任无关的事物，只注意与系统责任有关的事物。其次 ，对于与系统责任有关的事物，也不是把它们的任何特征 都在相应的对象中表达出来，而要舍弃那些与系统责任无 关的特征。判断事物是否与系统责任有关的关键问题，一 是该事物是否为系统提供了一些有用的信息(是否需要系 统为它保存和管理某些信息)；二是它是否向系统提供了 某些服务(是否需要系统描述它的某些行为)。 正确进行抽象，还需要考虑一些更深入的问题，即应该把 问题域中的事物映射为什么对象，以及如何对这些对象进 行分类。类的设置也可以有不同的决策。例如开发一个图 书馆管理系统时，设立“书”这个类，同时把每一本书作为 该类的一个对象。这样做是正确的，因为系统需要记住每 一本书借给了哪个读者。但在开发一个书店的业务管理系 统时，是否要把每一本书作为一个对象呢？实际上，在这 个系统中，把同一版本的一种书从总体上看成一个对象更 合理。因为该系统只要把每一种书看成一项货物，记住它 的货源、单价、库存量等信息就够了，不需记录每一本书 的信息。再如，在一个系统中，可以把管理者和工人设置 成不同的类，而在另一个系统中，也可以把所有的人员对 象都用同一个“人员”类来定义。 这些例子表明，如何把问题域中的事物抽象为对象和类， 可以有不同的选择。在不同的系统中，抽象的程度可以有 所不同。好的抽象应能清晰而简练地表达问题域，并使系 统的开销较少，这需要分析员根据不同系统的具体情况恰 如其分地运用抽象原则。 为了尽可能全面地发现系统所需要的对象，分析员应该把 握“先松后紧”的原则，即首先考虑各种能启发自己发现对 象的因素，尽可能找出各种可能有用的候选对象，宁可多 余，不可遗漏。然后对发现的候选对象逐个进行严格审查 ，筛选掉那些不必要的对象，或者对它们进行适当的调整 与合并，使系统中对象和类的数量尽可能少。 3. 寻找候选对象的基本方法 寻找候选对象的基本方法的主要策略是从问题域、系统边 界和系统责任三方面找出可能有的候选对象。 考虑问题域可以启发分析人员发现对象的因素。这些 因素包括人员、组织、物品、设备、事件、表格、结构等 。例如，从汽车这个对象向上可以联想到“车辆”，向下可 以联想到“客车”和“货车”，左右可以联想到“摩托车”；考 虑到整体和局部的关系，可以联想到“车队”和“发动机”或 “轮胎”。 考虑系统边界可以启发分析人员发现一些与系统边界 以外的活动者进行交互并处理系统对外接口的对象。考虑 的因素有人员、设备和外部系统。 考虑系统责任可以检查所存在的疏漏。通过对照系统 责任所要求的每一项功能，查看是否可以由现有对象完成 。 4. 审查和筛选对象 将所发现的对象进行审查和筛选，一般遵循如下原则： 舍弃无用对象。舍弃的标准一般是看对象是否提供了 有用的数据成员和成员函数，也就是对象所表现的行为特 征是否与要求有关。 对象精简。对于只有一个数据成员或只有一个成员函 数的对象，应考虑合并到相关对象中描述这个对象的特征 。 推迟到OOD考虑的对象。有些对象的特征在分析阶段 不需要描述，则放到OOD阶段再考虑。 5. 异常情况的检查和调整 还要对类的异常情况进行检查和调整。一般认为出现下述 情况都算异常情况，需要进行调整： 类的数据成员或成员函数不适合该类的全部对象。 数据成员或成员函数相同的类。 数据成员或成员函数相似的类。 对同一事物的重复描述。 经过这些步骤，就建立了类图的对象层。其实，这些就是 由对象名组成的一组对象图。 10.3 定义数据成员和成员函数 为了发现对象的数据成员，首先应考虑借鉴以往的OOA 结果，看看相同或相似的问题域是否有已开发的OOA模 型，尽可能复用其中同类对象数据成员的定义。然后重点 研究当前的问题域和系统责任，针对本系统应该设置的每 一类对象，按照问题域的实际情况，以系统责任为目标进 行正确地抽象，从而找出每一类对象应有的数据成员。 1. 寻找数据成员的一般方法 针对每个对象提出并回答以下问题，从而启发自己从各种 角度去发现对象的属性。下面是一般的考虑原则： 考虑按一般常识这个对象应该有哪些数据成员。对象 的某些数据成员往往是很直观的，按照一般常识就可以知 道它应该由哪些数据来描述。例如人的姓名、职业、地址 、电话号码等数据，都很容易想到。不过，按照一般常识 发现的数据成员有时未必真正有用，应该在审查时去掉那 些无用的数据。 在当前的问题域中，这个对象应该有哪些数据成员。 只有认真地研究当前问题域才能得到对象的数据成员。例 如商品的条形码，平常人们并不注意它，而考虑超级市场 这类问题域时，则会发现它是必须设置的数据。 根据系统责任的要求，这个对象应具有哪些数据成员 。对象的有些数据成员，只有具体地考虑系统责任才能决 定是否需要。如果系统做了修改，取消了这项功能，则与 此相关的数据肯定是要取消的。 建立这个对象是为了保存和管理哪些信息。例如在商 场管理系统中，建立“商品”对象，是为了由系统保存和管 理有关商品的哪些信息？或者说，是为了向系统提供有关 商品的哪些信息？通过这个问题而发现的信息应该由对象 的数据成员来表示。 对象为了在服务中实现其功能，需要增设哪些数据成 员。例如实时监控系统的传感器对象，为了实现其定时采 集信号的功能，需要一个“时间间隔”数据，为了实现其报 警功能，需要一个“临界值”数据。 对象有哪些需要区别的状态，是否需要增加一个数据 成员来区分这些状态。例如，设备在“关闭”、“待命”和“ 工作”等不同状态下系统中的行为是不同的，需要在“设备 ”对象中设立一个“状态”数据成员，用它的不同数据值来 表示实际设备的不同状态。 用什么数据成员表示整体-部分结构和实例连接。整体- 部分结构和实例连接在OOA模型中都有相应的符号（见 第1章），但也要在有关的对象中设立相应的数据成员。 对于整体-部分结构，整体对象应有表明其部分对象的数 据成员，可用嵌套对象或对象指针实现。 上面列出的问题都是为了从各种不同的角度启发分析员发 现对象的数据成员。有些数据成员在不同的问题的启发下 都能得到。这种导致相同结果的重复思考并不是坏事，因 为目标是尽可能全面地发现数据成员，宁可多费点事也不 要遗漏。 2. 审查与筛选数据成员 对于初步发现的数据成员，要进行审查和筛选。为此可对 每个数据成员提出以下问题： 这个数据成员是否体现了以系统责任为目标的抽象。 也就是说，该数据成员是否提供了系统中用得着的信息。 对现实世界中的事物如果脱离一定的目标去寻找它的特征 可以找出很多，OOA中应该只注意与系统责任有关的特 征。例如一本书有长、宽、高和重量，但是在图书馆管理 系统中，这些数据成员没有用就应该抛弃掉。 这个数据成员是否描述了这个对象本身的特征。一个 对象的数据成员应该描述这个对象本身的特征，否则即使 它在系统中提供了有用的信息，也不应该放置在这个对象 中。例如在教学管理系统中，“课程”这个对象，设“主讲 教师”这个数据成员是应该的，但是把教师的住宅、电话 号码作为课程的数据成员就不合适了（尽管使用这个系统 的教学管理人员可能感到这样做比较方便，他们可以从“ 课程”对象得知如何跟教师联系）。在现实世界中，一门 课程不会有地址和电话号码。正确的做法应该把“住址”和 “电话号码”作为“教师”对象的数据成员。这样才能与问题 域形成良好的对应，避免概念上的混乱，并避免因一个教 师主讲多门课程而出现的信息冗余。 该属性是否破坏了对象特征的“原子性”。认识事物的 特征应该按照日常的思维习惯采用原子的（即不可分的） 概念。例如人的通信地址，包括国家、省市、街道、门牌 号码和邮政编码等内容，但是这些内容在概念上是不可分 的。在定义“人员”对象的数据成员时，应该使用一个“通 信地址” 数据成员，而不应该把有关通信地址的各项内容 拆散开用多个数据成员来描述。这样，在对象中所定义的 数据成员，既可能是简单的数据项（例如人的性别、身份 证号码等），也可能是由多个数据项组成的较为复杂的数 据结构（例如通信地址、出生年月等）。每一个数据成员 都对应事物的一个原子特征。如果发现数据成员的设置破 坏了原子性，则应该加以修改。 这个数据成员是不是可以通过继承得到。如果当前对 象的类处于基类-派生类结构的派生类位置上，则检查 它的数据成员是不是可以通过继承来得到。凡是在基类中 定义了的数据成员，都不要在派生类中重复出现。 可以从其他数据成员直接导出的数据成员。如果一个 数据成员的值明显可以从另外一个数据成员的值直接导出 ，则应该去掉。例如“人员”对象有了“出生年月” 数据成 员，则“年龄”数据不必再保留。不太明显的信息冗余，即 一个数据成员的值可以从其他很多数据成员的值经过比较 复杂的计算才能导出，则OOA阶段暂不考虑其简化问题 ，以保留OOA模型的直观性。 3. 定义成员函数 类的数据成员有静态和非静态两大类。静态是整个类的所 有对象所共有，而不是只属于一个对象。 使用中要特别注意区分成员函数,非成员函数和友元函数 三者。成员函数和非成员函数之间最大的差异是：成员函 数可以是虚函数，而非成员函数不可以是虚函数。虚函数 必须是累的成员。友元函数不属于类，但在类中声明。 C+系统会自动产生一些看不到的默认成员函数，例如构 造函数、析构函数和赋值操作等等。但这些不一定符合 程序的要求，一定要为自己设计合适的成员函数，以免这 些默认函数达不到预期功能。 设计一个类时，要注意接口功能不仅要完整紧凑，而且要 使类的结构达到最小化。 发现对象的成员函数的策略可以参考发现数据成员的做 法，除了从系统责任和问题域方面考虑之外、还要分析对 象的状态及追踪服务的执行路线。一般要研究对象的状态 与转换图。在考虑对象的行为分类时，一般从系统行为和 对象自身的行为两方面考虑。 最后还要检查每个成员函数是否真正有用，它们是否有很 强的内聚性，进一步调整它们的成员函数。将获得的数据 成员和成员函数填入类图，就获得了类的特征层。 10.4 如何发现基类和派生类结构 定义对象之后，需要研究类之间的关系。因篇幅所限，本 节仅简要介绍如何从不同的角度努力发现可用的基类和派 生类结构。 借鉴同类问题域以往的OOA结果，吸取其经验，发现可 复用的系统成分，对于OOA的每一个活动都是有益的， 常常可以收到事半功倍的效果。 1. 学习当前领域的分类学知识 分类是一门学问，在许多行业和领域已经形成了一套科学 的分类方法。例如植物分类学、动物分类学、图书分类法 等都成为一门学科；又如生产物资、日用商品、医药、化 学药品等也都有一套行之有效的分类方法。分析员应该花 一番功夫学习一点与当前问题域有关的分类学的知识，因 为问题域现行的分类方（如果有）往往比较正确地反映了 事物的特征、类别以及各种概念的一般性与特殊性(恰好 对应C+的基类与派生类概念)。学习这些知识，将对 认识对象及其特征、定义对象的类、建立基类与派生类结 构有很大的帮助。按照本领域已有的分类方法，可以找出 一些与它对应的基类与派生类。 2. 按照常识考虑事物的分类 如果该问题域没有可供参考的现行分类方法，可以按照自 己的常识，从各种不同的角度考虑事物的分类，从而发现 其基类与派生类的关系。例如，对于“人员”可以从多种角 度去分类：青年人、成年人和老年人；男人和女人；黄种 人、白种人和黑种人；干部与工人；在职人员与离退休人 员；股东与职员；生产人员与销售人员等等。 从不同的角度考虑问题域中事物的分类，可以形成一些建 立基类与派生类结构的初步设想，从而启发自己发现一些 确实需要的基类与派生类结构。 需要提醒的是，分类要考虑是否符合分类学常识。基类与 派生类结构中的各个类之间的关系应该符合分类学的常识 和人类的日常思维方式，如果违背了这些，就会产生一种 怪异的、有悖常理的“结构”。例如，一个系统中先定义了 “汽车”这个类，它有“发动机”、“载重量”、“运行速度”等 数据成员和“运输”等操作的成员函数。在定义“飞机”这个 类的时候，发现它也有“汽车”的那些数据与成员函数，只 是增加了“飞行高度”等数据和“自动导航”等操作函数。于 是就从“汽车”类派生一个“飞机”类。这个结构是违背常理 的。因为这等于说“飞机是一种汽车”，这样的结构违背了 人类的常识，将使OOA模型难于理解。造成这种问题的 原因在于建立结构时只注意到继承，而没有注意到与问题 域的实际事物之间分类关系的对应。按分类学常识，它们 可以都是“运输工具”的派生类。 3. 回顾基类与派生类结构的两种定义 按照基类与派生类结构的两种定义，可引导我们从两种不 同的思路去发现基类与派生类结构。一种思路是把每一个 类看做是一个对象集合，分析这些集合之间的包含关系。 如果一个类是另外一个类的子集（例如“职员”是“人员”的 子集，“轿车”是“汽车”的子集），则它们应组织到同一个 基类与派生类结构中。另一种思路是看一个类是不是具有 另一个类的全部特征。这包括两种情况：一是建立这些类 时已经计划让某个类继承另一个类的全部成员，现在应建 立基类与派生类结构来落实这种继承；另一种情况是起初 只是孤立地建立每一个类，现在发现一个类中定义的成员 (数据成员和成员函数)全部在另一个类中重新出现，此事 应该考虑建立基类与派生类结构，把后者作为前者的派生 类，以简化其定义。 以上两种思路最终结果是相同的，但是作为两种不同的手 段可以互为补充。 4. 考察类的成员 对系统中的每个类，从以下两个方面考察它们的成员：一 是看一个类的成员是否适合这个类的全部对象。如果某些 数据成员和成员函数只能适合该类的一部分对象，说明应 该从这个类中划分出一些派生类，建立基类与派生类关系 。例如，“公司人员”这个类，如果有“股份”和“工资”两个 数据成员，通过审查可以发现，“股份”只能适应公司的股 东， 而“工资”数据则只适合公司的职员。因此应在“公司人员” 类下建立“股东”和“职员”两个派生类，并把“股份”和“工 资”分别放到这两个派生类中。这是一个“自上而下”的从 基类到派生类并形成结构的策略。 另一方面检查是否有两个（或更多的）类含有一些共同的 数据成员和成员函数。如果有，则考虑若把这些共同的数 据成员和成员函数提取出来，能否构成一个在概念上是包 含原来那些类的基类，组成一个基类与派生类结构。例如 系统中原先分别定义了“股东”和“职员”两个类，它们的“ 姓名”、“身份证号码”等数据成员是相同的，提取这些数 据成员可以构成一个“公司人员”类与“股东”及“职员”组成 基类与派生类结构。这是一个“自下而上”的从基类到派生 类并形成结构的策略。 还要对发现的结构进行审查、调整和简化，处理异常情况 ，才能建立合适的结构。 10.5 接口继承与实现继承 设计一个类是给别人使用的，也就是通过成员函数提供与 外界打交道的接口。成员函数有实成员函数、虚成员函数 和纯虚成员函数(本节分别简称为实函数、虚函数和纯虚 函数)3种，在实际中应该给用户提供哪些具体的成员函数 呢？现在假设设计一个可以供其他类继承的基类，派生类 是用公有继承方式。公有继承实际上是由两个不同部分组 成的，即函数接口的继承和函数实现的继承。这两种继承 之间的差异恰恰与函数说明和函数定义之间的差别是相对 应的。可概括成如下几点： 继承的总是成员函数接口。对于一个基类是正确的任 何事情，对于它的派生类必须也是正确的。 声明纯虚函数的目的是使派生类仅继承函数接口，而 函数的实现由派生类去完成。 声明虚函数的目的是使派生类既能继承默认的实现， 又能继承函数接口。 声明实函数的目的是使派生类既继承强制实现，又继 承函数接口。 可以使用如下某图形应用中表示几何形状的类层关系，来 比较上面这几种可能选择之间的差异： class Shape public: virtual void draw( ) const =0; virtual void error(const char *msg); int objectID ( ) const; . ; class Rectangle : public Shape .; class Ellipse : public Shape .; Shape是具有纯虚函数draw的抽象类，所以它不能建立 Shape类的实例，而只能由它派生的类去建立派生类的实 例。因为继承的总是基类成员函数的接口，所以Shape对 所有由它公有派生的类都产生很大影响。公有的继承指的 是“isa”，因此，对于一个基类是正确的任何事情， 对于 它的派生类必须也是正确的，即一个函数若适用于某个类 ，则一定也适用于它的子类。 在Shape类中声明了3个函数。第1个是draw， 用来在显示 器上画出当前的对象；第2个是error，用来报告出错；第 3个是objectID，它返回当前对象的一个惟一的整数标识 值。这3个函数的说明方法都不一样：draw是纯虚函数； 虽然虚函数error很简单，但不是纯虚函数；objectID则是 实函数。 1. 纯虚函数 纯虚函数最显著的两个特征是： 它们必须由继承它的非抽象类重新说明。 它们在抽象类中没有定义。 若将这两点放在一起，就说明一个纯虚函数的目的是使派 生类继承这个函数的接口。这要求所有的Shape对象都必 须是可作图的（当然该要求也是合理的），但Shape类不 能对该函数提供合理的默认实现。例如，画一个椭圆的算 法完全不同于画一个长方形的算法。解释 Shape : :draw() 的一个好办法是告诉子类的设计者：“必须提供draw函数 ，至于如何实现它，那是你自己的事。” 下面是使用纯虚函数的例句： Shape *ps=new Shape; / 出错! Shape是抽象类 Shape *psl=new Rectangle; / 正确 psl-draw ( ); / 调用Rectangle:draw Shape *ps2=new Ellipse; / 正确 ps2- draw( ); / 调用Ellipse:draw 有时，基类里仅仅说明纯虚函数也是很有用处的。这样 一种抽象的基类只给派生类提供函数接口，从来不提供实 现。 2. 虚函数 虚函数既提供函数的接口，也提供默认实现。虚函数的情 况不同于纯虚函数，派生类继承虚函数的接口，虚函数一 般只提供一个可供派生类选择的实现。之所以声明虚函数 ，目的在于使派生类既继承默认的实现，也继承函数接口 。 在Shape : error()的例句中，当接口请求遇到错误时，每 个类都必须支持一个准备调用的函数，而每个类也能自由 地并以其认为更合适