面向对象随想 -- 多用组合来代替继承
2011-05-06 11:19
302 查看
让我们先来简单看看什么是继承和组合。只是例子,不是概念。
假设有三个特性(模块), ModuleA, ModuleB, ModuleC。有两个类 ClassA 和 ClassB
需要使用它们。ClassA 会用到 ModuleA 和 ModuleB,ClassB
会用到全部三个特性。而且我们还假设现在全部A,B和C模块会只被ClassA和ClassB用到。
继承:
组合:
两种方法都重用了模块。
对于组合,我们一般把模块叫做组件。
在游戏开发中,这样的组合又叫做基于组件的实体系统。
组合比继承有哪些优势?
组合允许将问题分割成互不依赖的子元件。每个元件可以由不同的开发者开发。我们可以让三个程序员来同时开发 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"
(无引号),上百万的网页会支持这个观点。但这绝不是说在组合对继承的斗争中组合是赢家。不,而且根本没有斗争。对于适当的问题我们要选择适当的方法,保
证自然和逻辑性。没有什么是绝对的好或者坏,对或者错。
假设有三个特性(模块), 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"
(无引号),上百万的网页会支持这个观点。但这绝不是说在组合对继承的斗争中组合是赢家。不,而且根本没有斗争。对于适当的问题我们要选择适当的方法,保
证自然和逻辑性。没有什么是绝对的好或者坏,对或者错。
相关文章推荐
- 面向对象随想 -- 多用组合来代替继承
- 组合还是继承,这是一个问题?——由模式谈面向对象的原则之多用组合、少用继承
- 面向对象:类组合还是类继承?
- JS 面向对象之继承---多种组合继承详解
- JS 面向对象之继承--多种组合继承
- 面向对象(一)(封装,继承,多态,继承与组合,初始化块)
- 面向对象(11)(继承组合)
- 组合还是继承,这是一个问题?——由模式谈面向对象的原则之多用组合、少用继承
- 黑马程序员-Java的面向对象(抽象类、接口、内部类和继承、组合、多态)
- JavaScript面向对象——深入理解寄生组合继承
- 面向对象的继承与组合
- C++编程规范之34:用组合代替继承
- JavaScript面向对象的程序设计2(组合构造和原型 继承)
- JavaScript面向对象-基于原型链和函数伪装组合的方式实现继承
- C#面向对象(二)继承和组合
- 42_面向对象_15_继承_组合
- java学习之旅42--面向对象_15_继承_组合
- 面向对象的设计法则(1)——优先使用(对象)组合,而非(类)继承
- Objective-C----MRC内存管理 、 自动释放池 、 面向对象三大特性及封装 、 继承 、 组合与聚合
- 面向对象的设计法则-法则1:优先使用(对象)组合,而非(类)继承