网站大量收购闲置独家精品文档,联系QQ:2885784924

7 可工作的类.ppt

  1. 1、本文档共50页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
* 4.2 继承关系 继承的概念是指一个类是另一个类的特化 继承的目的是通过定义能为两个或更多派生类提供共有元素的基类的方式写更精简的代码 共有元素可以是子程序接口,内部实现,数据成员或数据类型等 50 * * 4.2.1 使用继承时要做的决策 对于每一个成员函数而言,它应该对派生类可见吗?它应该有默认的实现吗?这一默认的实现能被覆盖吗 对于每一个数据成员而言,它应该对派生类可见吗? 50 * * 4.2.2 继承中应该考虑的事项 用public继承来实现是一个的关系 要么使用继承并进行详细说明,要么就不要用它 遵循Liskov替换原则 确保只继承需要继承的部分 把公用的接口、数据及操作放到继承树中尽可能高的位置 避免让继承体系过深 尽量采用多态,避免大量的类型检查 50 * * 4.2.3 继承中应该考虑的事项 不要覆盖一个不可覆盖的成员函数 只有一个实例的类是值得怀疑的 只有一个派生类的基类也是值得怀疑的 派生后覆盖某个子程序,但在其中没做任何操作,这种情况也是值得怀疑的 应该让所有的数据类型都是private 50 * * 4.2.3.1 遵循Liskov替换原则 除非派生类真的是一个更特殊的基类,否则不应该从基类继承 派生类必须能通过基类的接口而被使用,且使用者无须了解两者之间的差异 换句话讲,对于基类中定义的所有子程序,用在它的任何一个派生类中时的含义都应该是相同的 50 * * 4.2.3.2 Liskov替换原则举例 class Base_Process { /// 数据处理基类 CString strSave_Path; /// 处理结果存贮路径 CString* getSave_Path; /// 得到存贮路径 virtual void Process() ; /// 通用接口 } class Diffirential_Process : public Base_Process { /// 积分处理类 void Process() ; } class Integral_Process : public Base_Process { /// 积分处理类 void Process() ; } … 应用 Base_Process m_Process[N]; for( int i =0 ;i N; i++ ) { m_Process[i].Process(); } 43 * * 50 * * 4.2.3.3 确保只继承需要继承的部分 继承而来的子程序有三种基本情况: 抽象且可覆盖的子程序是指派生类只继承了该子程序的接口,但不继承其实现 可覆盖的子程序是指派生类继承了该子程序的接口及其默认实现,并且可以覆盖该默认实现 不可覆盖的子程序是指派生类继承了该子程序的接口及其默认实现,但不能覆盖该默认实现 如果只想使用一个类的实现而不是接口则不要使用继承关系,而使用包含关系 50 * * 4.2.3.4 尽量使用多态,避免大量类型检查 频繁重复出现的case语句有时暗示采用继承可能是种更好的设计选择 50 * C++示例:多半应该用多态来替代的case语句 switch ( shape.type ){ case Shape_Circle: shape.DrawCircle(); break; case Shape_Square: shape.DrawSquare(); break; … } * 4.2.4 为什么有这么多关于继承的规则 从控制复杂度的角度说,继承是一件坏事,需要谨慎使用 如果多个类共享数据而非行为,应使用包含而非继承 如果多个类共享行为而非数据,使用继承 如果多个类既共享数据也共享行为,应该让他们从一个共同的基类继承,并在基类中定义共用的数据和子程序 当你想由基类控制接口时,使用继承,当你想自己控制接口时,使用包含 50 * * 4.3 成员函数和数据成员 对成员函数和数据成员的指导建议 让类中子程序的数量尽可能少 禁止隐式地产生不需要的成员函数和运算符 减少类所调用的不同子程序的数量 对其他类的子程序的间接调用要尽可能少(Demeter法则) 应尽量减少类和类之间相互合作的范围 50 * 4.3.1 Demeter法则 A对象可以任意调用它自己的所有子程序 如果A对象创建了一个B对象,它也可以调用B对象的任何公用子程序,但它应该避免再调用由B对象所提供的对象中的子程序 例如:account.getContactPerson()和account.contactPerson.daytimeContactInfo()允许 accou

文档评论(0)

整理王 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档