面向对象继承.ppt

面向对象继承
第1页，共81页，编辑于2022年，星期三
*
*
这种把继承作为一种扩展同时也作为一种收缩的思想，正是面向对象技术强大的原因，同时也会在正常的部署中引起混淆 。
扩展与简化
第2页，共81页，编辑于202，新类是基类的一种特定类型，它能满足基类的所有规范。 用这种方式创建的总是子类型，并明显符合可替换性原则。
与规范化继承一起，这两种方式构成了继承最理想的方式，也是一个好的设计所应追求的目标。
Window-TextWindow
特殊化继承
第16页，共81页，编辑于2022年，星期三
*
*
规范化继承用于保证派生类和基类具有某个共同的接口，即所有的派生类实现了具有相同方法界面的方法。
基类中既有已实现的方法，也有只定义了方法接口、留待派生类去实现的方法。派生类只是实现了那些定义在基类却又没有实现的方法。
规范化继承
第17页，共81页，编辑于2022年，星期三
*
*
派生类并没有重新定义已有的类型，而是去实现一个未完成的抽象规范。 也就是说，基类定义了某些操作，但并没有去实现它。只有派生类才能实现这些操作。
在这种情况下，基类有时也被称为抽象规范类。
规范化继承
第18页，共81页，编辑于2022年，星期三
*
*
在Java中，关键字abstract确保了必须要构建派生类。声明为abstract的类必须被派生类化，不可能用new运算符创建这种类的实例。除此之外，方法也能被声明为abstract，同样在创建实例之前，必须覆盖类中所有的抽象方法。
规范化继承可以通过以下方式辨认：基类中只是提供了方法界面，并没有实现具体的行为，具体的行为必须在派生类中实现。
GraphicalObject没有实现关于描绘对象的方法，因此它是一个抽象类。其子类Ball,Wall和Hole通过规范子类化实现这些方法。
规范化继承
第19页，共81页，编辑于2022年，星期三
*
*
一个类可以从其基类中继承几乎所有需要的功能，只是改变一些用作类接口的方法名，或是修改方法中的参数列表。
即使新类和基类之间并不存在抽象概念上的相关性，这种实现也是可行的。
构造继承
第20页，共81页，编辑于2022年，星期三
*
*
当继承的目的只是用于代码复用时，新创建的子类通常都不是子类型。这称为构造子类化。
一般为了继承而继承，如利用一些工具类已有的方法。
构造子类化
第21页，共81页，编辑于2022年，星期三
*
*
构造子类化经常违反替换原则（形成的子类并不是子类型）
构造子类化
第22页，共81页，编辑于2022年，星期三
*
*
与特化子类化相反？
派生类扩展基类的行为，形成一种更泛化的抽象。
Window-ColoredWindow
泛化子类化
第23页，共81页，编辑于2022年，星期三
*
*
泛化子类化通常用于基于数据值的整体设计，其次才是基于行为的设计。
泛化子类化
第24页，共81页，编辑于2022年，星期三
*
*
如果派生类只是往基类中添加新行为，并不修改从基类继承来的任何属性，即是扩展继承。（泛化子类化对基类已存在的功能进行修改或扩展，扩展子类化则是增加新功能）
由于基类的功能仍然可以使用，而且并没有被修改，因此扩展继承并不违反可替换性原则，用这种方式构建的派生类还是派生类型 。
扩展继承
第25页，共81页，编辑于2022年，星期三
*
*
如果派生类的行为比基类的少或是更严格时，就是限制继承。
常常出现于基类不应该、也不能被修改时。
限制继承可描述成这么一种技术：它先接收那些继承来的方法，然后使它们无效。
双向队列-〉堆栈
限制继承
第26页，共81页，编辑于2022年，星期三
*
*
由于限制继承违反了可替换性原则，用它创建的派生类已不是派生类型，因此应该尽可能不用。
限制继承
第27页，共81页，编辑于2022年，星期三
*
*
两个或多个类需要实现类似的功能，但他们的抽象概念之间似乎并不存在层次关系。
控制鼠标=控制触摸屏
但是，在概念上，任何一个类作为另一个类的子类都不合适
因此，可以选择其中任何一个类作为父类，并改写与设备相关的代码
变体子类化
第28页，共81页，编辑于2022年，星期三
*
*
但是，通常使用的更好的方法是将两个类的公共代码提炼成一个抽象类，比如PointingDevice，并且让这两个类都继承于这个抽象类。
与泛化子类化一样，但基于已经存在的类创建新类时，就不能使用这种方法了。
变体子类化
第29页，共81页，编辑于2022年，星期三
*
*
可以通过合并两个或者更多的抽象特性来形成新的抽象。
一个类可以继承自多个基类