面向对象随想 -- 多用组合来代替继承

kbasm

已于 2023-08-30 09:49:38 修改

阅读量1.2k

点赞数 1

文章标签： class objective c inheritance 工作编程语言

于 2011-04-22 13:13:00 首次发布

本文链接：https://blog.csdn.net/kbasm/article/details/6341159

版权

让我们先来简单看看什么是继承和组合。只是例子，不是概念。
假设有三个特性（模块）， ModuleA, ModuleB, ModuleC。有两个类 ClassA 和 ClassB 需要使用它们。ClassA 会用到 ModuleA 和 ModuleB，ClassB 会用到全部三个特性。而且我们还假设现在全部A，B和C模块会只被ClassA和ClassB用到。

继承：

class ClassA { functions of ModuleA; functions of ModuleB; }; class ClassB extends ClassA { functions of ModuleC; };

组合：

class ModuleA {}; class ModuleB {}; class ModuleC {}; class ClassA { ModuleA ma; ModuleB mb; }; class ClassB { ModuleA ma; ModuleB mb; ModuleC mc; }; //或者： class ClassB { ClassA ca; ModuleC mc; };

两种方法都重用了模块。

对于组合，我们一般把模块叫做组件。
在游戏开发中，这样的组合又叫做基于组件的实体系统。

组合比继承有哪些优势？

组合允许将问题分割成互不依赖的子元件。每个元件可以由不同的开发者开发。我们可以让三个程序员来同时开发 ModuleA， ModuleB 以及 ModuleC。
元件可以在运行时被替换，删除，或者添加（动态绑定）。与之相反，继承不能或者非常难（取决于编程语言）在运行时替换，删除，或者添加特性（静态绑定）。
组合比继承有更少的耦合。继承强制了 ClassB 和 ClassA 之间的耦合，但组合不会。
组件可以被用在其它的组合当中用以构成不同的行为。在继承中则没有办法只重用一个单个特性。继承强制了父类的所有特性被带入到了子类。
更少的代码冗余。继承比较容易导致冗余。B 继承自 A，通常 B 只需要 A 的部分特性，不需要的部分就成了冗余。如果 B 是由 A 的部分元件组合来的，那么 B 可以舍弃不需要的元件来避免冗余。
更好的封装。组合是基于公开接口的。每个元件不知道其它元件的内部细节。这正是封装所指的。而继承则把父类的内部细节（保护的接口）透露给了子类。更糟的是，子类通常会对父类做某些假设，而且父类也会假设子类会尊重它要求的接口。
容易更改。在组合中，任何元件都可以被更改而保证对其它元件影响很小，只要保持公开的接口。继承则强制了很紧密耦合的层次链。对于层次链任何节点的改变都将影响整个链。
小模块和原子模块。组合中，大的模块是由小的模块组成的，因此模块的层次可以得到控制。有可能我们只有两个层次，原子模块，和真实的功能模块，因而层次非常平坦。在继承中，大的模块来自从小的模块继承。想要一个模块？继承吧，得到一个新的层级。这就可能造成有很多的层级，导致系统的模块层次非常复杂且难以理解。

对于 "is a" 关系我们应该用继承？是，也不是。

虽然我们被教导继承要 "is a" 组合要 "has a"，在很多情况下 "is a" 也可以被理解为 "has a"。比如说，程序员是一种人，所以程序员从人继承。但如果我们把程序员当成是一种具有编程工作的人，那么程序员就可以由人和编程工作来组合。

组合的不足之处：
唯一的不足之处大概就是我们最终会得到非常多的模块（类）。这个很难说是不足，而且从其它角度看，这个其实是益处。对于C++，大量的小类完全没有影响，不会让代码变大，也不会让运行变缓慢。对于 Java，C#，Objective C，这可能会增大代码。但除非你是工作在资源有限的设备上，这个不是大问题。

何时用组合：

当 ClassB 使用 ClassA 而不是实现 ClassA 时。
当元件会被改变时（添加，替换，删除）。
即使 ClassB 和 ClassA 具有 "is a" 的关系，如果这种关系在未来会发生变化，我们应该用组合而不是继承。一个程序员是人，但未来他可以选择别的工作，比如股票经纪。如果程序员是从人继承而来，那么当工作变化时我们就比较麻烦。因此用组合。程序员只是一个普通的人，一个有着编程工作的普通人。
当继承不是必须的时候。没错，我们要多用组合来代替继承。

何时用继承：

当 ClassB 是实现 ClassA 而不是使用 ClassA。比如说，ClassA 可能是具有多态函数的抽象对话框，有着显示隐藏等函数。ClassB 是一个文件对话框需要实现这些多态函数。
当 ClassB 和 ClassA 有明显的 "is a" 关系而且这种关系不会在运行时改变时。也就是说，绑定永远是静态的。虽然猫可以被当成是一个具有动物特征和猫特征的物体，但这两个特征永远不会改变。把猫特征换成狗特征会产生狗而不是猫。所以这种绑定是静态的，关系也是固定的 "is a"，所以让猫从动物继承是很自然的。
当 ClassA 的接口也是 ClassB 的接口时。这个其实很难讲。如果用组合实现其实也可以，ClassB 可以重写代理接口来重定向到 ClassA 上。
当 ClassB 会被用到使用 ClassA 的地方时。这个也暗喻了 ClassB "is a" ClassA。然而，对于支持类型多态（泛型编程）的语言，比如 C++，可以通过用模板类型来避免继承。

总结：

我展示了我们应该多用组合而不是继承。而且如果你 google "composition inheritance" （无引号），上百万的网页会支持这个观点。但这绝不是说在组合对继承的斗争中组合是赢家。不，而且根本没有斗争。对于适当的问题我们要选择适当的方法，保证自然和逻辑性。没有什么是绝对的好或者坏，对或者错。