第01讲　面向对象设计实例（一）　　

本章先讨论在实际应用中需要考虑的几个专题：
　　如何发现对象
　　如何发现对象的数据成员和成员函数
　　如何定义数据成员和成员函数
　　如何发现基类和派生类结构
　　如何考虑接口继承与实现继承
　　最后给出一个设计实例。
　　本章的目的是加深对知识的理解并锻炼解决实际问题的能力，希望通过本章的学习，能将所学知识正确地运用到实际中去。
　　主要内容
　　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++系统会自动产生一些看不到的默认成员函数，例如构造函数、析构函数和赋值操作等等。但这些不一定符合程序的要求，一定要为自己设计合适的成员函数，以免这些默认函数达不到预期功能。
　　设计一个类时，要注意接口功能不仅要完整紧凑，而且要使类的结构达到最小化。
　　发现对象的成员函数的策略可以参考发现数据成员的做法，除了从系统责任和问题域方面考虑之外、还要分析对象的状态及追踪服务的执行路线。一般要研究对象的状态与转换图。在考虑对象的行为分类时，一般从系统行为和对象自身的行为两方面考虑。
　　最后还要检查每个成员函数是否真正有用，它们是否有很强的内聚性，进一步调整它们的成员函数。将获得的数据成员和成员函数填入类图，就获得了类的特征层。

第02讲　面向对象设计实例（二）　　

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（）的例句中，当接口请求遇到错误时，每个类都必须支持一个准备调用的函数，而每个类也能自由地并以其认为更合适的方式处理出错。如果一个类并不想做任何特别的处理，亦可退回到Shape类中提供的默认出错处理中去，即Shape::error（）要求子类设计者必须支持一个error函数， 但是如果他不想编写自己的error函数，也可以使用Shape类里的默认error函数。
　　需要注意的是，如果允许虚函数同时去指定函数声明和默认参数，则是件很危险的事情。所以一定要慎用虚函数的默认参数。
　　3.实函数
　　最后再来讨论Shape的实函数objectID。 当一个成员函数是实函数时，无论派生类如何变化，它都是不会有所变化的。所以说，一个实成员函数指定它自己在派生类中保持不变。因此，声明实函数的目的是使派生类既继承强制的实现，也继承其函数接口。
　　可以考虑Shape::objectID（）的说明，每个Shape对象都有一个能生成对象标识值的函数，而且每个对象标识值总是以相同的方法计算的。这完全是由Shape::objectID（）的定义所决定，任何一个派生类都不应尝试改变它的行为。由于实函数代表的意义是“不变性”高于“变异性”，所以不应该在派生类中重新定义它。
　　4.避免重新定义继承的实函数
　　虽然在派生类中重定义基类的同名实函数，可以使用域分辨符解决访问问题，但那纯粹是从语义上分析问题。这里是从使用安全角度看问题，为了提高程序质量，在实际应用中应避免这样做。
　　5.注意事项
　　纯虚函数、虚函数以及实函数之间的差别，使程序员可以相当精确地指定派生类的继承方式：仅继承接口，还是继承接口和默认行为，或是继承接口和一份实现代码。因为这些不同类型的声明意味着并不相同的事情，因此在声明成员函数时，必须慎重选择。如果这样做，就能够避免经验不足的类设计者们最常犯的如下两种错误：
　　①把所有的函数都声明成实函数。它没有在派生类里给特殊化留下一点余地；把析构函数都说明成实函数尤其成问题。当然，当设计一个不打算作为基类使用的类时，这样做是非常合理的，而且一组专用的实成员函数也是合适的。其实应该注意虚函数与实函数间的差异，因为在实际应用中，用做基类的类都会拥有一些虚函数。
　　②把所有的成员函数笼统地说明成虚函数。好听一点的说法是它适合于任何类，说难听一点则是没有任何用途。当然有时候还是正确的，例如抽象基类。但在很多情况下，函数并不需要在派生类中重新定义。应该把不需要重新定义的成员函数声明为实函数。如果使用者把大量时间花在了函数的重定义上，将无法体会类的用途。

10.6 设计实例

　　本节的设计任务是使用Point类产生Line类。Line类有颜色和宽度属性。
　　Line通过包含及派生两种方式实现，派生方式需要演示公有继承的赋值兼容性规则、虚函数的多态性和友元函数。注意它们的构造函数和复制构造函数的设计方法。
　　10.6.1使用包含设计的方法
　　1.Line的结构图
　　2.设计Point类
　　3.设计Line类
　　10.6.2使用包含的参考程序及运行结果
　　1.cpp10.h文件
　　2.cpp10.cpp文件
　　3.Find10.cpp文件
　　4.运行结果
　　10.6.3使用继承的设计方法
　　1.Line的结构图
　　2.设计类
　　10.6.4使用继承的参考程序和运行结果
　　1.cpp101.h文件
　　2.cpp101.cpp文件
　　3.Find101.cpp文件
　　4.输出结果