OO基础之继承
1 两种继承
传统的观点一般把继承分为两种：实现继承和接口继承。关于这两种继承的说法也有很多，个人比较接受Bjarne Stroustrup的说法：
实现继承：是子类的一个实现细节，这种细节并不反映在子类的类型（接口）中。
接口继承：也叫subtyping，子类继承父类的接口，并且允许父类类型到子类类型的隐式转换。也就是说，父类和子类是一种基类型-子类型关系，满足LSP原则：子类型必须能替换掉其基类型。
以我的理解，实现继承纯粹是一种实现技术，目的是为了重用其他类的代码。它的出发点是子类，父类只是子类的实现的一部份，若不考虑依赖性，则子类的接口和父类的接口是不相关的。而接口继承则表达了父类的对象与子类的对象间一种可替换的关系，子类的接口包含了父类的接口。在静态语言中，比如C++和java，支持抽象和多态的关键机制之一就是接口继承，正是通过接口继承，我们才能够在不影响客户代码的情况下扩展基类型。
从设计的观点看，实现继承等价于包容，除了覆盖问题之外（见注1）。可能出于简单性的考虑，出现较晚的各种面向对象语言大都没有提供对实现继承的直接支持，这时的继承就只是接口继承了：Java用extends和implements来表示，C#则直接用冒号。C++还是提供了更多地选择：用public派生来表达接口继承，用private和protected派生来表达实现继承。
2 继承的误用
继承的误用和滥用很常见，特别是在那些把继承简单地看作语言层提供的另一种代码复用机制的人那里。主要有两种情况：
在该使用包容的地方使用继承。导致这种误用一大诱因是继承使用起来很方便，写法上也简单（可直接访问父类的操作），但是也付出了增加依赖关系的代价：当子类覆盖了父类的虚函数时，父类就将依赖于其子类去实现它的部分功能，当然，有时我们会期望这样的行为，比如说在适用template method模式的情况，但当我们的本意不是这样的时候，该依赖就会带来麻烦。如果把包容关系误用成接口继承时，还存在忘记子类到父类的隐式类型转换的问题，除非你的语义允许这种转换的发生。同时，继承还限制了限制了一个子类对象只能包含的一个父类对象，灵活性上也有不足。包容表达的是一种"has a"关系，接口继承基本上是一种"is a"关系，而实现继承则强调一种实现细节。
在该使用实现继承的地方使用接口继承。如果只考虑代码复用，实现继承可以实现的，接口继承都可以实现，同时接口继承还具有实现继承没有的继承接口的功能，这也就是为什么接口继承常常泛滥的原因。这种误用的结果当然是违反了LSP原则。
从以上可以看出，把继承简单地看成是另一种代码复用的机制是不够的，因此Bjarne Stroustrup才说：基本上只应该将派生（继承）用于表述设计中定义良好的关系。
代码是设计思想的表达，良好的代码应该能够使阅读者正确地领会其设计意图，比如，当看到C++程序里一个类D从类B公有派生，阅读者就有理由作出这样的假设：在所有针对B编写的函数中，如果传入D的对象，函数应该能保持正确的行为。如果该代码的编写者却说"我可不是这么设计的"，那么代码就变得难以理解了。
3 继承和UML
最后谈一下继承在UML中的表示。由于UML并不是只为软件系统建模，所以没有继承关系，代之以泛化关系，用泛化关系来表达软件领域里的继承关系。如果是接口继承的话，直接用一个指向父类的三角肩头来表示，对实现继承，则通过应用到泛化关系上的一个构造型 implementation 来表示，如下图
244
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
